Date: Thu, 24 Jun 1999 15:22:36 -0500 (EST) From: Alfred Perlstein <bright@rush.net> To: Karl Denninger <karl@Denninger.Net> Cc: "Brian F. Feldman" <green@unixhelp.org>, Doug <Doug@gorean.org>, Mark Newton <newton@internode.com.au>, drosih@rpi.edu, grog@lemis.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: Microsoft performance (was: ...) Message-ID: <Pine.BSF.3.96.990624150634.14320D-100000@cygnus.rush.net> In-Reply-To: <19990624145755.B8280@Denninger.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Jun 1999, Karl Denninger wrote:
> On Thu, Jun 24, 1999 at 02:33:10PM -0400, Brian F. Feldman wrote:
> > On Thu, 24 Jun 1999, Karl Denninger wrote:
> >
> > > On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote:
> > > > We're adding some machines at work for (essentially) cgi
> > > > processing only. It was never considered to use anything less than 2 cpu
> > > > boxes, and the current round of testing is going so well that we're
> > > > seriously considering 4 cpu boxes because they are not that much more
> > > > expensive and our processing is highly CPU bound. I agree that redundancy
> > > > is a good thing, but at some point the increased network latency exceends
> > > > the point of diminishing returns for the redundancy factor.
> > > >
> > > > In short, increasing SMP efficiency should really be a priority
> > > > for N>2 systems.
> > >
> > > Agreed. But this is a BIG job, because to do that you have to solve the
> > > "one big kernel lock" problem and go to fine-grained locking. This is a
> > > non-trivial job.
> >
> > We don't need fine-grained locks. We would get good performance if we
> > could get (say) per-subsystem locks.
>
> That's still a non-trivial task. :-)
A simple start would be to explicitly put a macro or call in each
syscall to push down the lock. That way people can move that
macro farther and farther down in the syscall code path, hopefully
removing it entirely in some cases. I think having the call at
the beginning of each syscall would motivate people into doing that
sort of work.
"Hey, y'know getppid() is safe, i'll just take the lock out."
"this function xxx() is safe until this point I can process a lot
before actually needing this lock..."
"y'know I just have a structure that's not accessable to any other calls
that i'm going to fill in, i'll just lift the lock right here"
"if I just do this something here, I really am re-entrant and safe.."
Providing a simple api for spinlocks and mutexes would be very nice.
If some of the FreeBSD gods (core) said something along the lines
of we'd like to see the process table have XXX method of access
and locking people will code it, the same way with the many other
subsystems.
Things like pmap and UFS and INET will be a royal pain to get
SMP safe, however baby steps towards lifting the lock for
simpler subsystems will lead the way. FreeBSD has the
most intellegent people in the industry working together,
all that is needed is a starting point.
-Alfred Perlstein - [bright@rush.net|bright@wintelcom.net]
systems administrator and programmer
Win Telecom - http://www.wintelcom.net/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990624150634.14320D-100000>