Date: Fri, 24 Mar 2000 15:55:52 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Preliminary SMP/BGL patch Message-ID: <20000324155552.V21029@fw.wintelcom.net> In-Reply-To: <200003241759.JAA14699@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Mar 24, 2000 at 09:59:16AM -0800 References: <200003241759.JAA14699@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Dillon <dillon@apollo.backplane.com> [000324 10:23] wrote: > A preliminary BGL patch is now on my site, relative to RELENG_4. > > http://www.backplane.com/FreeBSD4/ > > It is the smp-patch-03.diff item at the end of the first section. > > My test box successfully built the world. I know I'm probably missing > something, but so far I can't tell what it might be because nothing > is failing :-) > > This is considered very alpha and has been made available mainly to > endgender discussion. You know, things like "Matt, you've really gone > off the deep end this time! You cannot *DO* that to the syscall > interface!". Do it! do it! do it! :) > My primary assumption is that read access to fields in curproc plus any > structural references that are 'static'-like (e.g. like ucred) are legal > without having to hold the BGL. So getuid() can be made BGL safe > but getppid() cannot (nor can getpid() because compatibility mode also > returns the ppid). Obviously there are other fine-grained solutions. > > The biggest assumption in the patch is that doreti does not have to be > called for system calls. Being able to get rid of it for syscalls means > being able to do an end-run around doreti's extremely SMP-unsafe code. This sort of concerns me, but if I remeber correctly, unmasking spl will cause a soft intr if there are pending interupts, the only problem is that completely software initiated interupts wouldn't get processed, or would they? Can you explain how they are being scheduled/run if you remove doreti()? One alternative would be to call doreti() only in the syscalls with the MPunsafe flag set, although I'm probably missing something that makes doreti() totally unnessesary, it may be that clock interupts are covering your removal of doreti(). FYI, I was tempted to commit this with "Submitted by: dillon" and watch the fur fly, it is 5.0 after all. :) As things progress I think multi-subsystem locks expressing intent for structure manipulation would be a very cool idea, although I need to think about it more. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000324155552.V21029>