tech-kern archive

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

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

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.


Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index