Jason Thorpe wrote:
On Oct 4, 2009, at 5:00 PM, Jean-Yves Migeon wrote:Hi list, I would like to introduce a new function to the pool_cache(9) API, namely pool_cache_invalidate_local() (see [1] for patch and documentation). Basically, it is similar to pool_cache_invalidate(), except that it invalidates the per-CPU caches for the current CPU executing the calling thread. The reason for why I would like to have such a function is to add support for Xen save/migrate/restore functionality under PAE. Reasons follow.Maybe I'm missing something ... how is this ever safe to use? An object can be allocated from one CPU's cache and freed to another.
I hardly see how that would be possible. During pool_get/pool_put, the only per-CPU pool cache that is manipulated is the current_cpu() one. If one's CPU is manipulating the pool_cache of another, bad things will happen anyway, as two CPUs could release at the same time in the same pool_cache. Without locks, this sounds wrong.
The routine that is never safe is the pool_cache_invalidate_cpu(), when called for a CPU different from the current one running. But this function is never exposed to the outside world.
The per-CPU cache is simply an optimization, and it seems very wrong to expose this implementation detail to consumers of the API.
I need a way to invalidate all pool caches, even those that are CPU-bound. pool_cache_invalidate() only does that for the global cache, as it cannot invalidate CPU caches for CPUs other than its own.
Before invalidate_local(), the only way would be to destroy the pool_cache entirely, just to release the objects found in pc_cpus[]. This would cripple down the entire VM system, as it cannot work without the L2 shadow page pool.
In Xen's case, pool_cache_invalidate_local() would be used by each CPU during its detach routine (just before its shutdown), to clear all its associated L2 pages that Xen cannot handle.
Cheers, -- Jean-Yves Migeon jeanyves.migeon%free.fr@localhost