tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Name cache locking issue?

Hm, ok... False sharing of the lock itself. I can buy that. However, I think this strategy is going to need a review as soon as we support processors coming and going.

-- thorpej@iPhone

On Apr 12, 2008, at 7:23 AM, Andrew Doran <> wrote:

On Fri, Apr 11, 2008 at 07:21:11PM -0700, Jason Thorpe wrote:

We should make it MI.

But why not just use an rwlock?

rwlocks are slow on MP systems. The below is output from a test program I have, running on a dual core Intel chip. It creates one thread per CPU and each thread does the same task in a loop. It's using the pthread library but for the purposes of the test the locks work the same way as the kernel.

281814791 function calls / sec
32194373 thread private, uncontested mutex acquire/release / sec
20950637 thread private, uncontested rwlock acquire/release / sec
5605204 dummy systems calls / sec
3420158 global, uncontested rwlock acquire/release / sec


-- thorpej@iPhone

On Apr 11, 2008, at 4:59 PM, Andrew Doran <> wrote:

On Fri, Apr 11, 2008 at 04:21:17PM -0700, Jason Thorpe wrote:

On Apr 11, 2008, at 8:25 AM, Andrew Doran wrote:

Module Name:    src
Committed By:    ad
Date:        Fri Apr 11 15:25:24 UTC 2008

Modified Files:
 src/sys/kern: kern_cpu.c vfs_cache.c
 src/sys/sys: cpu_data.h namei.src

Log Message:
Restructure the name cache code to eliminate most lock contention
resulting from forward lookups. Discussed on tech-kern@.

Hm, is cache_lock_cpus() safe if CPU_INFO_ITERATOR() happens to
the CPUs in a different order on different CPUs?

A quick check shows that they all start from the same point (the
first CPU)
so it should be OK. I guess we should document that somewhere, and
maybe get
rid of the MD macro altogether.


Home | Main Index | Thread Index | Old Index