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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
