Re: pool_cache_invalidate(9) (wrong?) semantic -- enable xcall invalidation

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

On Tue, 8 Nov 2011 22:53:09 -0500, Thor Lancelot Simon wrote:
> On Wed, Nov 09, 2011 at 01:51:23AM +0100, Jean-Yves Migeon wrote:
> > 1 # adding an "invalidate flag" to the pool cache, for each CPU.
>
> How about a serial number, instead.  Locally in each CPU's pool 
> cache,
> globally for the entire kernel.  pool_cache_invalidate increments the
> serial number with an atomic operation; before each allocation on any
> CPU, that CPU checks whether its local serial number matches the 
> global
> one.  If not, invalidate, then retry the operation.  Repeat as 
> necessary.

This is the idea. One shortcoming though: the pool_cache(9) content is 
not synchronously invalidated, depleting the per-CPU cache would only 
happen when the CPU pool_cache_get() a new object.

From an API perspective is it ok for everyone? In my case, I'll have to 
xcall(9) a pool_cache_get() for each CPU to force-deplete the pools 
because of Xen shortcomings (it tracks page types and will raise an 
exception when pages are not freed on a suspension).

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