[PATCH] futexes, flash9 related

[Alexander Leidinger]

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

Bye,
Alexander.

-- 
BOFH excuse #170:

popper unable to process jumbo kernel

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