[PATCH] futexes, flash9 related

[Kostik Belousov]

On Fri, Feb 06, 2009 at 12:21:03PM +0100, Alexander Leidinger wrote:
> Quoting Kostik Belousov <kostikbel at gmail.com> (from Fri, 6 Feb 2009  
> 11:28:21 +0200):
> 
> >On Fri, Feb 06, 2009 at 09:47:28AM +0100, Alexander Leidinger wrote:
> >>Quoting Chagin Dmitry <dchagin at freebsd.org> (from Fri, 6 Feb 2009
> >>09:35:50 +0300):
> >>
> >>>On Thu, Feb 05, 2009 at 08:20:13AM -0200, Renato Botelho wrote:
> >>>>On Sun, Dec 21, 2008 at 3:49 PM, Chagin Dmitry <dchagin at freebsd.org>
> >>>>wrote:
> >>>>>
> >>>>> Hi,
> >>>>> /me ready to present patches for testing (nor review).
> >>>>>
> >>>>> The primary goal - the futexes code is rewrited, Giant removed.
> >>>>>
> >>>>> head: http://people.freebsd.org/~timur/dchagin/mega-head.linux.patch
> >>>>> stable/7: 
> >>http://people.freebsd.org/~timur/dchagin/mega-st7.linux.patch
> >>>>>
> >>>>> Please, test and report any problems. thnx!
> >>>>
> >>>>Hello,
> >>>>
> >>>>I would like to test this because i'm having some freezes on
> >>>>firefox3 + flash9 + 8.0-current i386 r188003 but the patch
> >>>>doesn't apply cleanly here, is there a new version that i've
> >>>>missed?
> >>>>
> >>>
> >>>hi,
> >>>try http://lnxx64.googlecode.com/files/futexes_partial.patch
> >>
> >>Please let the DEBUG part as it is, I'm in the process of converting
> >>it to DTrace
> >>(http://svnweb.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/).
> >
> >DTrace is absolutely unsuitable for getting the _traces_ from the kernel,
> >as well as the kernel printfs. Moreover, use of KTR is in-line with other
> >tracing points in *our* kernel.
> 
> Could you please be more specific (maybe some examples) about what you  
> mean by "unsuitable"? Maybe I have a different understanding of  
> "traces" than you have. For the places where KTR is used in _this  
> patch_, DTrace seems to be suitable to me.
> 
> AFAIR KTR needs to be specially enabled at compile time, while DTrace  
> can be enabled at run-time. Is the KTR part correct? If yes, I see a  
> benefit in using DTrace instead of KTR. Apart from that, DTrace has  
> some advantages (DTrace scripts, limiting the tracing to just use  
> within a specific application, conditional tracing, ...) over KTR, so  
> if it is not something performance critical where DTrace is not able  
> to handle it but KTR is, or something which DTrace is not able to  
> handle at all, I see no point in not converting to DTrace (it has the  
> advantage that it can be used even on a production system, where I  
> wouldn't let KTR in the kernel on a production system).

1. KTR does not require any user-mode support or action; in particular,
   it is useful for after-the-panic analysis, while DTrace is not.
2. Our DTrace support, is, to say it mildly, not quite matured.
   DTrace to be yseful also needs specially compiled kernel, that is not
   absolutely trivial at the moment.
3. As I said, DTrace probes are orthogonal to KTR. Put them in, if
   you want. It is not /instead/.

Said this, I do not see a reason to block KTR patch. Absolutely different
question is when to commit it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20090206/a4db684e/attachment.pgp