tlb flushing on Power
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:
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 :-)
More information about the Linuxppc-dev