SMP-Style Kernel Locking

[mike at bilow.com (Michael Bilow)]

First, the locks are not the issue.  The only possible effect of a lock is
to make the other CPUs spin in place.  It there are no other CPUs, then
the lock owner is by definition not restricted and no CPUs exist which
could be restricted.  There is probably a very tiny overhead introduced by
setting, resetting, and checking the lock status, but I doubt this could
even be measured.

Of greater concern would be that certain optimizations which are allowed
under a uniprocessor system would be disallowed under a multiprocessor
system.  Most of these would be actions which make use of some nonshared
resource, such as the cache or a video accelerator.  This sort of thing
would be hard to measure, although it might be large, because the
complexity of interactions could make only certain rarely encountered
pathological situations interesting.  For example, you might find that
your system bottleneck suddenly becomes the scatter-gather algorithm in
your SCSI controller, which is obviously not what you want to test.

I assume you are aware that there are radical changes to the SMP locking
scheme between kernels 2.2 and 2.4, especially with regard to granularity.

-- Mike


On 2000-12-05 at 05:12 -0000, Ming Chow wrote:

> I am currently doing some investigation on SMP-style kernel locking (on 
> single processor machines).  I have compiled an SMP-enabled kernel on a 
> single processor machine.  I am trying to see if there are any performance 
> differences between SMP kernel locking and a non-SMP kernel locking (i.e. if 
> anything slows down).  If there are, what can I do in the kernel source code 
> to prove or show the performance differences? Any help would be greatly 
> appreciated!  Thanks!

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).