Messages in this thread | | | Date | Tue, 27 May 2014 11:56:44 -0500 (CDT) | From | Christoph Lameter <> | Subject | Re: [RFC][PATCH 0/5] VM_PINNED |
| |
On Tue, 27 May 2014, Peter Zijlstra wrote:
> > Code could be easily added to alloc_pages_vma() to consider the pinned > > status on allocation. Remove GFP_MOVABLE if the vma is pinned. > > Yes, but alloc_pages_vma() isn't used for shared pages (with exception > of shmem and hugetlbfs).
alloc_pages_vma() is used for all paths where we populate address ranges with pages. This is what we are doing when pinning. Pages are not allocated outside of a vma context.
What do you mean by shared pages that are not shmem pages? AnonPages that are referenced from multiple processes?
> So whichever way around we have to do the mm_populate() + eviction hook > + migration code, and since that equally covers the anon case, why > bother?
Migration is expensive and the memory registration overhead already causes lots of complaints.
| |