Re: [RFC] 2.3/4 VM queues idea

Matthew Dillon
2000-05-26T16:55:47Z

:Hi,
:
:On Fri, May 26, 2000 at 06:36:40PM +0200, Jamie Lokier wrote:
:
:> That's ok. VA == vma->pgoff + page_offset. Move a vma and that's still
:> true. The ptes are found by looking at the list of all vmas referring
:> to all the address_spaces that refer to a page.
:
:And that is _exactly_ the problem --- especially with heavy mprotect()
:use, processes can have enormous numbers of vmas. Electric fence and
:distributed shared memory/persistent object stores are the two big,
:obvious cases here.
:
:--Stephen

I don't think this will be a problem. FreeBSD's vm_map_entry scheme
is very similar and we found it to be fairly trivial to optimize adjacent
entries in many cases for both madvise() and mprotect(). In fact, half
the madvise() calls (such as MADV_WILLNEED, MADV_DONTNEED, and MADV_FREE)
have no effect on the vm_map_entry (VMA equivalent) at all, they operate
directly on the associated pages.

The only fragmentation issue I've ever seen with our vm_map_entry scheme
occurs when you use mprotect() to create a guard page for each thread's
stack. The creation of the guard page forces the vm_map_entry to be
broken up, preventing the vm_map_entries for adjacent stack segments
from being collapsed together into a single entry.

You wind up with two vm_map_entry's per thread. Not really a problem,
but somewhat of an eyesore.

In regards to overhead, anything that collects a bunch of pages together
(e.g. vm_map_entry, vm_object under FBsd, VMA in Jamie's scheme)
simply does not create a memory overhead issue. None at all. It's
the things that eat memory on a per-page basis that get annoying.

-Matt
Matthew Dillon
<dillon@backplane.com>