[PATCH] futexes, flash9 related

Fri Feb 6 05:08:37 PST 2009

Quoting Kostik Belousov <kostikbel at gmail.com> (from Fri, 6 Feb 2009  
14:00:51 +0200):

> 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.

Yes, but you need to have KTR compiled in for this to work. And when  
you compile it it, it will generate traces for all events within the  
mask. So either you have a -1 mask to trace everything at any time, or  
you can not really do an after-the-panic analysis at all.

If you only want to enable it when you reproduce the panic, then  
DTrace can be used too (the DTrace probes will fire before a panic, as  
the KTR events will be generated before a panic). You can even limit  
the tracing in the kernel depending on the program which initiated the  
call of kernel functions, so you can narrow down the trace to the  
really interesting stuff, instead of creating a pile of KTR logs and  
try to filter out uninteresting stuff yourself.

All in all I see KTR as something for pure debugging in an controlled  
environment. Nothing to enable by default in GENERIC. KDTRACE_HOOKS on  
the other hand is something for GENERIC and for controlled debugging  
environments (except for time critical stuff).

> 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.

You need "options KDTRACE_HOOKS", the rest can be loaded as a module.  
I would say this is trivial. For KTR you need to have "options KTR"  
and maybe some more options. So the argument of a specially compiled  
kernel does not matter.

AFAIK KDTRACE_HOOKS was supposed to be activated by default, now that  
the licensing issues are resolved, but I don't remember why it isn't.  
I also don't remember why WITH_CTF is not the default at least in  
-current, so yes, there's room for improvement, but even without CTF  
enabled during buildworld you can already do useful stuff with dtrace  
(at least regarding kernel stuff).

> 3. As I said, DTrace probes are orthogonal to KTR. Put them in, if
>    you want. It is not /instead/.

I asked to not remove the ifdef DEBUG stuff, as I already remove it  
while I add DTrace probes (I hope this will make the merging more easy  
in case I commit my stuff after his stuff comes in). It also serves as  
some kind of TODO item for me.

I did _not_ ask to remove the KTR stuff. I agree that both can  
coexists (but I don't see a point in having the KTR stuff in the  
linuxulator when DTrace is mature in FreeBSD).

> Said this, I do not see a reason to block KTR patch. Absolutely different
> question is when to commit it.

That's the reason why I asked to let the ifdef DEBUG part there. I  
would not be surprised if this patch is committed before I commit the  
DTrace stuff, and I hope that it will be more easy for me to merge the  
DTrace stuff when the DEBUG parts stay.

Bye,
Alexander.

-- 
If some people didn't tell you,
you'd never know they'd been away on vacation.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137