Date: Fri, 22 Mar 2002 10:05:19 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: smp@FreeBSD.ORG Subject: Re: Giant instrumentation Message-ID: <XFMail.20020322100519.jhb@FreeBSD.org> In-Reply-To: <200203220019.g2M0Jcw03488@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-Mar-2002 Matthew Dillon wrote: > >:Kelly Yancey implemented most of the syscall Giant instrumentation >:stuff I outlined in an earlier e-mail. I have since mostly finished >:it and changed a few things. Most of the changes were design changes >:so that the instrumentation stuff was as separated from the rest of >:the kernel (and thus easily condionitionally compiled out with minimal >:impact) as possible. Also, it now provides better support for handling >:other ABIs. It's not complete yet (it only has instrumentation for >:the native ABI at the moment) but I wanted to post this patch for >:feedback. I have tested it some and it is being tested some more on >:alpha and x86 at the moment. The patch can be found at: >: >:http://www.FreeBSD.org/~jhb/patches/giantvars.patch >: >:-- >: >:John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > > This is extreme overkill. Unless you an Kelly plan on doing all > the work of instrumenting everything, I don't think many developers > are going to want to deal with this. I certainly don't. I think what > I have in there now not only works just fine, it's also easily > understood and straightforward. This patch is unnecessarily complex > and way too far disassociated (hidden) from the code it is supposed > wrap to be of any tangible benefit to -current development. > > I know I'm being harsh here, but that is my opinion. Er, instead of adding s = mtx_lock_giant()/mtx_unlock_giant() along with having to possibly rework logic of code, you just add "foo" to a line in syscalls.giantvars. This is hard? The main difference here is that the instrumentation code no longer impacts the actual syscall source code thus keeping the actual syscall code cleaner. Also, in your current implementation you encourage both safe and unsafe code to be under the sysctl variables meaning that we can't actually get Giant out from under a subsystem until the whole thing is done preventing us from incrementally moving things out from under Giant. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020322100519.jhb>