Re: Adding pool_cache_invalidate_local() to pool_cache(9) API

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

On Fri, Oct 09, 2009 at 09:11:20AM -0700, Jason Thorpe wrote:
> 
> On Oct 9, 2009, at 6:44 AM, Manuel Bouyer wrote:
> 
> > As pointed out by Jean-Yves, this is the documented behavior of
> > pool_cache_invalidate(). x86 pmap uses it in a similar way, and checks
> > that items allocated from the cache are not stale before use.
> 
> Ok.  I did not add the per-CPU caching stuff, so I was not aware of this 
> behavior... but it seems wrong, and I think it should be changed.  It can be 
> very expensive (probably much more expensive than taking an uncontested 
> mutex) to check for stale objects.  And, as I said before, this is different 
> than how Solaris's kmem_cache works, and kmem_cache is what pool_cache was 
> modeled after when I originally wrote it.

A lock is too expensive on a modern, pipelined out-of-order system but it
does work well on older, in-order systems with relatively short pipelines.

A broadcast cross call works just as well and
the invalidator pays the price as he should.  I can't remember if it works
this way and I don't know what has been done while I was AWOL.