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 8, 2009, at 11:52 PM, Jean-Yves Migeon wrote:

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.

This patch should solve the problem.  Please try it out.

It does not work.

The kernel locks very early during boot (even before console initialization in domU, so I am left with a very limited debugging environment).

The reason is the KASSERT(xc_tailp < xc_headp) in xc_lowpri(), when called through xc_broadcast().

In my case, the quirk happens in mi_cpu_attach(), when creating the idle lwp. Basically, pool_cache_invalidate() now has a dependency on xc facilities. For x86, if VM ressources are scarce, nothing prevent uvm(9) from increasing the kernel VM through pmap_growkernel(). This will result in an invalidation of the PDP pool_cache, with a call to xc_broadcast.

However, only the boot processor is running at this stage, and it's still not flagged SPCF_RUNNING (it happens during configure2()). As a result, xc_broadcast() will never increment xc_headp (see its code), and the KASSERT() fires.

I am wondering if we could not set this flag earlier for the BP. I do not see how this could affect boot, hardware interrupts are masked until autoconf is entered, and secondary CPUs will be initialized during configure2() anyway...

Other than that, I like it. pool_cache(9) looks cleaner that way, indeed.

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


Home | Main Index | Thread Index | Old Index