Date: Sun, 25 Jun 2000 23:27:25 -0700 (PDT) From: Frank Mayhar <frank@exit.com> To: Nate Williams <nate@yogotech.com> Cc: Terry Lambert <tlambert@primenet.com>, Daniel Eischen <eischen@vigrid.com>, Jason Evans <jasone@canonware.com>, smp@FreeBSD.ORGG Subject: Re: SMP meeting summary Message-ID: <200006260632.XAA43962@realtime.exit.com> In-Reply-To: <200006260442.WAA15731@nomad.yogotech.com> from Nate Williams at "Jun 25, 2000 10:42:02 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > Dynix had no problem with 32 processors. Most SVR4 variants, and > > I will include Solaris in this, use mutex protection of structures, > > and start to fall down drastically over 4 processors. > Amazing that you say this, yet I see extremely good results on Solaris > boxes up to 64 processors. Hmm. Do you have numbers? > Suffice it to say that I'm not convinced, nor am I convinced that > mutex's around data structures is any different than critical > sectioning. > > They are essentially the same thing, in that the critical section is > almost always the code that deals with a particular (shared) data > structure. I agree with this, but I can state that Unixware doesn't scale well (i.e. linearly) over roughly four (or possibly eight, its been a while since I looked at the numbers) processors. This has been clearly shown by various and sundry benchmarks at Compaq and elsewhere. I do like the "per-cpu pool" idea, though (although I haven't yet thought it completely through). This would have to, I think, go along with a much stronger CPU affinity for threads and interrupts. I clearly see that, under 4.0, processes pretty much freely migrate from CPU to CPU. This is bad for SMP performance (kills the cache) and would also mean that if a process using a particular structure were on a different CPU, it would have to either move to the proper CPU or move the structure into the per-CPU pool of the CPU it's using. Or use a non-CPU-pool structure. I'll have to think about this some more. It's an interesting idea, though. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://store.exit.com/ 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?200006260632.XAA43962>