Re: What to expect with the 2.6 VM

[Andrea Arcangeli <andrea@suse.de>]

On Thu, Jul 03, 2003 at 04:46:26AM -0700, William Lee Irwin III wrote:
> Actually it's not entirely for vma overhead. Compacting the virtual
> address space allows users to be "friendly" with respect to pagetable
> space or other kernel metadata space consumption whether on 32-bit or
> 64-bit. For instance, the "vast and extremely sparsely accessed"
> mapping on 64-bit machines can have its pagetable space mitigated by
> userspace using the remap_file_pages() API, where otherwise it would
> either OOM or incur pagetable reclamation overhead (where pagetable
> reclamation is not yet implemented).

apps should never try to use remap_file_pages like that in 64bit,
mangling the ptes, flushing tlb and entering kernel is an huge overhead
compared to the static pte ram cost that nobody can care about on 64bit
since as worse you can plug some more giga of ram. If you really have an
huge chunk that you've to release (and the problem isn't at all the pte,
the problem if something is the page pointed by the pte that you may
want to free if you know it'll never be useful again), munmap will work
fine too and it won't be slower than remap_file_pages and if it's a
really huge chunk munmap will get rid of the ptes too.

btw, for the really huge mappings largepages are always required anyways
which means the pte cost is zero because there aren't ptes at all.

even if you don't use largepages as you should, the ram cost of the pte
is nothing on 64bit archs, all you care about is to use all the mhz and
tlb entries of the cpu.

remap_file_pages is useful only for VLM in 32bit and theoretically
emulators (but I didn't hear any emulator developer ask for this feature
yet, and I doubt it would make a significant performance difference
anyways since the only thing that saves is the vma cost for the emulator
since you want to leave rmap behind it)

Andrea
--
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:"aart@kvack.org"> aart@kvack.org </a>