tlb flushing on Power

Benjamin Herrenschmidt benh at kernel.crashing.org
Fri Jan 27 13:40:40 EST 2012


On Thu, 2012-01-26 at 14:30 -0800, Dave Hansen wrote:
> On 01/26/2012 01:39 PM, Benjamin Herrenschmidt wrote:
> > Can you explain to me a bit more the whole business in this patch set
> > about doing kmap_atomic() vs. manually trying to populate the PTEs ? 
> 
> They're compressing pages and the allocator is trying getting very poor
> packing of compressed pages in to PAGE_SIZE chunks.  So, they're moving
> to 2-page allocations that they need to be mapped contiguously to make
> it easier on the users of the allocator.
> 
> > Why not just use two kmap atomic entries ? If interrupts are disabled
> > kmap_atomic() should give you contiguous ones I suppose
> 
> I think you and I are at least on the same page on this one:
> 
> https://lkml.org/lkml/2012/1/26/355

Right. We probably want to document this somewhere if we start relying
on that behaviour or at the very least add a WARN_ON() and fail from the
compressed allocator if we end up with non-contiguous pages.

> > (unless NMIs are allowed to use kmap_atomic, are they ?)
> 
> Surely they can't be.  Even if they could use it, they'd have to return
> the __kmap_atomic_idx back to the place where it started before they
> returned, so the interrupted code wouldn't notice.

Ah indeed, that's for talking before I had breakfast :-)

Cheers,
Ben.




More information about the Linuxppc-dev mailing list