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>
index | next in thread | previous in thread | raw e-mail
Quoting Kostik Belousov <kostikbel@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@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.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 = 72077137help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090206140817.56246os28cq390o4>