Date: Mon, 28 Apr 1997 14:15:28 -0400 From: "David S. Miller" <davem@jenolan.rutgers.edu> To: terry@lambert.org Cc: ccsanady@nyx.pr.mcs.net, black@zen.cypher.net, chuckr@mat.net, FreeBSD-SMP@FreeBSD.org Subject: Re: SMP Message-ID: <199704281815.OAA00308@jenolan.caipgeneral> In-Reply-To: <199704281741.KAA02151@phaeton.artisoft.com> (message from Terry Lambert on Mon, 28 Apr 1997 10:41:47 -0700 (MST))
next in thread | previous in thread | raw e-mail | index | archive | help
From: Terry Lambert <terry@lambert.org> Date: Mon, 28 Apr 1997 10:41:47 -0700 (MST) These are isolated subsystems. They don't ever reenter code on multiple CPU's simultaneously. Yes we most certainly do re-enter code for numerous things, currently: 1) System calls which modify process signal disposition 2) Signal delivery itself 3) sys_wait4() 4) A huge slew of "easy" system calls (getpid(), sys_times(), these sorts of things) Are all multi-threaded and can all run on all processors simultaneously. Just as a quick example on my 3 processor development Sparc machine. ? ./lat_sig lat_sig Signal handler installation: 4.993 microseconds Signal handler overhead: 37.701 microseconds Protection fault: 59.407 microseconds Ok, now this: ? Signal handler installation: 3.933 microseconds Signal handler installation: 3.835 microseconds Signal handler installation: 3.730 microseconds Signal handler overhead: 46.994 microseconds Signal handler overhead: 44.269 microseconds Signal handler overhead: 46.942 microseconds Protection fault: 78.210 microseconds Protection fault: 96.422 microseconds Protection fault: 74.614 microseconds While not entirely obvious, it does at least appear that the signal specific parts of this benchmark run about the same with one invocation as 3 do in parallel. The fault cost is noticably more for the multiple invocation, showing how the master lock is still necessary for the mm/vfs subsystems. We are working on threading those as well as the networking right now. Also since the scheduler is completely SMP safe, heavily user bound processes can run in and out of the scheduler without the master lock. We also have SMP safe wait queues already, and have solved the lost wakeup problem even for SMP already... Furthermore our interrupt handling subsystem is completely SMP safe, interrupt handlers can run in parallel on all processors at once. The correct approach to incremental improvement is "push down". You define locking primitives that assume transitive closure over all the other locks in the kernel (ie: that there is a hierarchical relationship and intention modes), and initially run them all off the single lock. Yes Terry, we all know about your transitive closures... ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704281815.OAA00308>