Subject: Re: scheduler woes on MPACPI kernel
To: None <current-users@NetBSD.org>
From: William Allen Simpson <firstname.lastname@example.org>
Date: 01/18/2005 17:19:29
Frank van der Linden wrote:
>On Tue, Jan 18, 2005 at 08:25:51PM +0000, email@example.com wrote:
>>So there is no point in having MP system if it actually increases total
>>Somebody did a benchmark recently of NetBSD vs FreeBSD and NetBSD came
>>on top. So people said if it was done on a MP system, FreeBSD would be
>>faster, due to finer-grained locking, etc. Any ideas if that's true?
>That depends, highly, on the kind of benchmark in question. For threaded
>benchmarks that spend a fair amount of time in the kernel, finer grained
>locking should win out. Problem is, that not many of those seem to
>exist. It'd be interesting to see actual real-world application comparisons
>for such situations.
Long ago, there was the CDC 6600. 2 CPUs, 10 PPU (peripheral cpus),
all accessing central memory.
Fine grained kernel locking turned out to be a bad idea. Performance
came with moving almost all central management out of the PPUs, and
making only 1 CPU handle all system functions. Huge improvement!
There's a tremendous amount of overhead in locking. Even with the
very nice built-in 1 cycle test and modify instructions (exploiting
the fact that core memory destroys the value on read, so it has to be
written again anyway).
Ahh, they don't make such handy instruction sets anymore. That Cray was
quite a fellow....
fast 1 cycle variable bit rotation.
population count instruction (the number of bits set in a 60-bit word).
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32