Date: Fri, 06 Feb 2009 14:08:17 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-emulation@freebsd.org, Chagin Dmitry <dchagin@freebsd.org> Subject: Re: [PATCH] futexes, flash9 related Message-ID: <20090206140817.56246os28cq390o4@webmail.leidinger.net> In-Reply-To: <20090206120051.GO9427@deviant.kiev.zoral.com.ua> References: <20081221174939.GA33531@dchagin.dialup.corbina.ru> <747dc8f30902050220y7b1d726bj9f6f83afa843b520@mail.gmail.com> <20090206063550.GA2123@dchagin.static.corbina.ru> <20090206094728.10822rj93nm7s280@webmail.leidinger.net> <20090206092821.GM9427@deviant.kiev.zoral.com.ua> <20090206122103.9886475rqvyhdt2c@webmail.leidinger.net> <20090206120051.GO9427@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Kostik Belousov <kostikbel@gmail.com> (from Fri, 6 Feb 2009 =20 14:00:51 +0200): > On Fri, Feb 06, 2009 at 12:21:03PM +0100, Alexander Leidinger wrote: >> Quoting Kostik Belousov <kostikbel@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@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@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.patc= h >> >>>>> 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 othe= r >> >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 =20 you compile it it, it will generate traces for all events within the =20 mask. So either you have a -1 mask to trace everything at any time, or =20 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 =20 DTrace can be used too (the DTrace probes will fire before a panic, as =20 the KTR events will be generated before a panic). You can even limit =20 the tracing in the kernel depending on the program which initiated the =20 call of kernel functions, so you can narrow down the trace to the =20 really interesting stuff, instead of creating a pile of KTR logs and =20 try to filter out uninteresting stuff yourself. All in all I see KTR as something for pure debugging in an controlled =20 environment. Nothing to enable by default in GENERIC. KDTRACE_HOOKS on =20 the other hand is something for GENERIC and for controlled debugging =20 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. =20 I would say this is trivial. For KTR you need to have "options KTR" =20 and maybe some more options. So the argument of a specially compiled =20 kernel does not matter. AFAIK KDTRACE_HOOKS was supposed to be activated by default, now that =20 the licensing issues are resolved, but I don't remember why it isn't. =20 I also don't remember why WITH_CTF is not the default at least in =20 -current, so yes, there's room for improvement, but even without CTF =20 enabled during buildworld you can already do useful stuff with dtrace =20 (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 =20 while I add DTrace probes (I hope this will make the merging more easy =20 in case I commit my stuff after his stuff comes in). It also serves as =20 some kind of TODO item for me. I did _not_ ask to remove the KTR stuff. I agree that both can =20 coexists (but I don't see a point in having the KTR stuff in the =20 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 =20 would not be surprised if this patch is committed before I commit the =20 DTrace stuff, and I hope that it will be more easy for me to merge the =20 DTrace stuff when the DEBUG parts stay. Bye, Alexander. --=20 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 =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090206140817.56246os28cq390o4>