From owner-freebsd-emulation@FreeBSD.ORG Fri Feb 6 13:08:35 2009 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD336106564A; Fri, 6 Feb 2009 13:08:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2D18FC1B; Fri, 6 Feb 2009 13:08:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2EB9A.dip.t-dialin.net [217.226.235.154]) by redbull.bpaserver.net (Postfix) with ESMTP id 1A9922E047; Fri, 6 Feb 2009 14:08:22 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 8CDC11396E6; Fri, 6 Feb 2009 14:08:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1233925698; bh=bDy3t3vckT0wTALdCbe9z7VeME7N59SnC 5CvByqlTKE=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0N7gInDxH7i+CqvB9JKjdGUkbUwxo8XjqHslF6cPoaVxXTCQ1ycfZPpqpVMSKh5j0 u7uDAZUVJzfEciw9nyo07LSyCUQHxdJp12nmaY3e+PhTQlewIVZAcSvSK+3w5tfkG1n wwIR8Ws9BsxwC9Z+5M1Ep1MZjwHtoq4FQc8w7WumKP7+OWB7pSqDFEaSgrOii7emPjH 4NCVUICazvxMQ316HOnj5kRk9pou7bzu7Fvir6rfrNuUUIAmX8496xMyp4/M9yXtkFL RxYBcR2JcgYh00jwYEMp4U4rCHRyus6OxHrs864u5GcnPBtg68Q/un/eJgomIptlpuD pV60bIhMA== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n16D8Ihn080798; Fri, 6 Feb 2009 14:08:18 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 06 Feb 2009 14:08:17 +0100 Message-ID: <20090206140817.56246os28cq390o4@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 06 Feb 2009 14:08:17 +0100 From: Alexander Leidinger To: Kostik Belousov 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> In-Reply-To: <20090206120051.GO9427@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 1A9922E047.724C8 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-13.504, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-emulation@freebsd.org, Chagin Dmitry Subject: Re: [PATCH] futexes, flash9 related X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 13:08:37 -0000 Quoting Kostik Belousov (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 (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 (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 >> >>>>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