On Tue, May 27, 2014 at 09:34:22AM -0500, Christoph Lameter wrote: > On Tue, 27 May 2014, Peter Zijlstra wrote: > > > The things I care about for VM_PINNED are long term pins, like the IB > > stuff, which sets up its RDMA buffers at the start of a program and > > basically leaves them in place for the entire duration of said program. > > Ok that also means the pages are not to be allocated from ZONE_MOVABLE? Well, like with IB, they start out as normal userspace pages, and will be from ZONE_MOVABLE. > I expected the use of a page flag. With a vma flag we may have a situation > that mapping a page into a vma changes it to pinned and terminating a > process may unpin a page. That means the zone that the page should be > allocated from changes. So the only way to 'map' something into pinned is what perf does (have the f_ops->mmap call set VM_PINNED). But that way already ensures we have full control over the allocation since its a custom file. And in fact the perf buffer is allocated with GFP_KERNEL and is thus already not from MOVABLE. Any other use, like (again) the IB stuff, will go through get_user_pages() which will ensure all the pages are mapped and present. So I don't think this is a real problem and certainly not one that requires a page flag. > Pinned pages in ZONE_MOVABLE are not a good idea. But since "kernelcore" > is rarely used maybe that is not an issue? Well, the idea was to migrate pages to a more suitable location on mm_mpin(). We could choose to move them out again on mm_munpin() or not. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>