Hi,

rwessel (robertwessel@yahoo.com) on 5/15/06 wrote:
---------------------------
>Nick's point is that modern OS's spend more time bouncing cachelines (to acquire
>uncontended locks or processes lock-free structures or whatever), than they do waiting on contended locks.

>Excessive lock contention is clearly a problem, but has not been a real issue for modern kernels for some time.

I _do_ understand this, I just don't see how seperating everything so that only one process has access to each "thing" would make scalability suck or make me 10 years behind.

Cacheline contention caused by the message queue lock in a micro-kernel will be as bad as cachline contention caused by a device driver's own lock in a system where the device driver runs in the context of some other process, so swapping one for the other doesn't seem to make any difference to me.

If anything, a system where the device driver runs in the context of some other process would have worse cacheline contention and worse scalability because of the device driver accessing it's own local data from any CPU that happened to run it.

The only way I can think of to remove cacheline contention would be to make sure that the device driver (or server or whatever) is only ever used by processes/threads running on the same CPU (so that the cache line/s are never touched by other CPUs), but this type of optimization would work equally well regardless of the type of kernel.


Cheers,

Brendan