Subject: Re: CVS commit: [vmlocking] src/sys/kern
To: Jason Thorpe <thorpej@shagadelic.org>
From: Andrew Doran <ad@netbsd.org>
List: source-changes
Date: 09/11/2007 12:20:20
On Mon, Sep 10, 2007 at 02:12:19PM -0700, Jason Thorpe wrote:
> Sun didn't seem to think that a lock would be too terrible in this
> case. Why not take their advice?
Because I think we can do better than that! Take a ficticious example: an
i386 system doing 50,000 alloc / free pairs a second that can be handled
purely by the CPU local part of its caches. Since it's x86 it doesn't need
to do memory barriers beyond the interlocked cmpxchg in mutex_enter(), and
it can do mutex_exit() with a non-interlocked cmpxchg. It depends on the CPU
you're using but say it's about 150 cycles to grab a lock. There will be an
aborted trip through mutex_enter() half of the time because some of the
caches are spinlocked. So each alloc / free pair spends perhaps 450 cycles
on locking, times 50,000 that's a lot of cycles, and it doesn't take into
account the serializing properties of the interlocked instructions.
Andrew