Re: Name cache locking issue?

[Andrew Doran <ad%netbsd.org@localhost>]

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

Andrew

> -- thorpej@iPhone
> 
> On Apr 11, 2008, at 4:59 PM, Andrew Doran <ad%netbsd.org@localhost> 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  
> >>return
> >>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.
> >
> >Andrew