Messages in this thread | | | Date | Mon, 12 May 2014 09:16:38 +0400 | Subject | Re: [PATCHv2 0/2] remap_file_pages() decommission | From | Konstantin Khlebnikov <> |
| |
On Mon, May 12, 2014 at 7:36 AM, Andi Kleen <andi@firstfloor.org> wrote: > Armin Rigo <arigo@tunes.org> writes: > >> Here is a note from the PyPy project (mentioned earlier in this >> thread, and at https://lwn.net/Articles/587923/ ). > > Your use is completely bogus. remap_file_pages() pins everything > and disables any swapping for the area.
Wait, what's wrong with swapping pages from non-linear vmas? try_to_umap() can handle them, though not very effectively.
Some time ago I was thinking about tracking rmap for non-linear vmas, something like second-level tree of sub-vmas stored in non-linear vma. This could be done using exising vm_area_struct, and in rmap tree everything will looks just as normal. We'll waste some kernel memory, but it also will remove complexity from rmap and make non-linear vmas usable for all filesystems not just for shmem.
But it's not worth. I ACK killing it.
Maybe we should keep flag on vma and hide/merge them in proc/maps. Bloating files/dirs in proc might be bigger problem than non-existent performance regression.
> > -Andi > -- > ak@linux.intel.com -- Speaking for myself only > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
| |