| From | Sent On | Attachments |
|---|---|---|
| Jason Evans | Jun 24, 2000 11:56 pm | |
| Daniel Eischen | Jun 25, 2000 6:58 am | |
| Terry Lambert | Jun 25, 2000 10:12 am | |
| Terry Lambert | Jun 25, 2000 10:36 am | |
| Julian Elischer | Jun 25, 2000 10:41 am | |
| Poul-Henning Kamp | Jun 25, 2000 11:07 am | |
| Nate Williams | Jun 25, 2000 9:41 pm | |
| Frank Mayhar | Jun 25, 2000 11:27 pm | |
| Frank Mayhar | Jun 25, 2000 11:31 pm | |
| Luoqi Chen | Jun 26, 2000 9:46 am | |
| Arun Sharma | Jun 26, 2000 9:47 am | |
| Jason Evans | Jun 26, 2000 11:06 am | |
| Matthew Dillon | Jun 26, 2000 12:26 pm | |
| Matthew Dillon | Jun 26, 2000 12:48 pm | |
| John Sconiers | Jun 26, 2000 12:56 pm | |
| Matthew Dillon | Jun 26, 2000 1:07 pm | |
| Luoqi Chen | Jun 26, 2000 1:13 pm | |
| Doug Rabson | Jun 26, 2000 1:26 pm | |
| Jason Evans | Jun 26, 2000 2:56 pm | |
| Jason Evans | Jun 26, 2000 3:14 pm | |
| Daniel Eischen | Jun 26, 2000 4:59 pm | |
| Luoqi Chen | Jun 26, 2000 7:14 pm | |
| Jason Evans | Jun 26, 2000 7:55 pm | |
| Joe Eykholt | Jun 26, 2000 8:09 pm | |
| Greg Lehey | Jun 27, 2000 8:00 pm | |
| Jason Evans | Jun 27, 2000 8:25 pm | |
| Daniel Eischen | Jun 27, 2000 8:26 pm | |
| Greg Lehey | Jun 27, 2000 9:59 pm | |
| Greg Lehey | Jun 27, 2000 10:11 pm | |
| Terry Lambert | Jun 28, 2000 4:15 pm | |
| Terry Lambert | Jun 28, 2000 4:18 pm | |
| Terry Lambert | Jun 28, 2000 4:37 pm | |
| Terry Lambert | Jun 28, 2000 4:51 pm | |
| Arun Sharma | Jun 28, 2000 9:43 pm | |
| Greg Lehey | Jul 2, 2000 7:15 pm | |
| Daniel Eischen | Jul 3, 2000 3:23 am | |
| Greg Lehey | Jul 3, 2000 3:30 am | |
| Jeroen C. van Gelderen | Jul 3, 2000 7:55 am | |
| Chuck Paterson | Jul 3, 2000 8:28 am | |
| Chuck Paterson | Jul 3, 2000 8:47 am | |
| Frank Mayhar | Jul 3, 2000 8:49 am | |
| Greg Lehey | Jul 3, 2000 4:08 pm | |
| David Scheidt | Jul 3, 2000 4:35 pm | |
| Joe Eykholt | Jul 3, 2000 4:47 pm | |
| Greg Lehey | Jul 3, 2000 4:52 pm | |
| Joe Eykholt | Jul 3, 2000 4:58 pm | |
| Greg Lehey | Jul 3, 2000 5:26 pm | |
| Joe Eykholt | Jul 3, 2000 5:41 pm | |
| Chuck Paterson | Jul 3, 2000 7:17 pm | |
| Daniel Eischen | Jul 3, 2000 7:25 pm | |
| Daniel Eischen | Jul 3, 2000 7:35 pm | |
| Greg Lehey | Jul 3, 2000 7:39 pm | |
| Daniel Eischen | Jul 3, 2000 7:41 pm | |
| Chuck Paterson | Jul 3, 2000 8:40 pm | |
| Alfred Perlstein | Jul 3, 2000 10:08 pm | |
| Greg Lehey | Jul 3, 2000 10:37 pm | |
| Peter Wemm | Jul 4, 2000 2:43 pm | |
| Greg Lehey | Jul 4, 2000 3:58 pm | |
| Peter Wemm | Jul 4, 2000 4:06 pm | |
| Terry Lambert | Jul 5, 2000 3:38 pm | |
| Terry Lambert | Jul 5, 2000 4:00 pm | |
| Terry Lambert | Jul 5, 2000 4:06 pm | |
| Terry Lambert | Jul 5, 2000 4:10 pm | |
| Alfred Perlstein | Jul 5, 2000 4:29 pm | |
| Terry Lambert | Jul 6, 2000 4:50 pm |
| Subject: | Re: SMP meeting summary | |
|---|---|---|
| From: | Frank Mayhar (fra...@exit.com) | |
| Date: | Jun 25, 2000 11:27:03 pm | |
| List: | org.freebsd.freebsd-smp | |
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 fra...@exit.com http://www.exit.com/ Exit Consulting http://store.exit.com/
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message





