tech-kern archive

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

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

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

Home | Main Index | Thread Index | Old Index