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

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On Fri, 9 Oct 2009 07:35:14 -0700, Matt Thomas <matt%3am-software.com@localhost>
wrote:
> On Oct 9, 2009, at 2:51 AM, Jean-Yves Migeon wrote:
>> If there is a lockless ("or contention-free mutex") way to do it,  
>> why not.
>> But this will alter a performance-critical code path, and should be  
>> thought
>> out very carefully.
> 
> Do it lazily.  Set a flag in each per-cpu queue and next time an item  
> that
> cpu accesses its per-cpu cache, it can see the cache is invalid and  
> discard it.
>
> This doesn't solve the window of that cpu already actively using the  
> pool
> while the flag is set but it could that could solved by get testing  
> the test on
> exit, if set discarding the item, and retrying.
> 
> No reason for exposing the mechanics of how to do this to the users of  
> the
> poll APIs.

You would still have to provide a function to invalidate local per-CPU
pcgs; or else, each CPU would have to call pool_cache_invalidate(), and for
each call, this will deplete the global cache, even if it contains valid
objects. You could solve this by adding an extra parameter to
pool_cache_invalidate to indicate "global" or "local+global" invalidation,
but this is not much different from _invalidate and _invalidate_local.

BTW, that would require to add memory barriers for each call to
pool_put/pool_get, to ensure flag coherency across CPUs. Are such barriers
really performance friendly?

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost