Re: [RFC] 2.3/4 VM queues idea

Matthew Dillon
2000-05-26T17:35:30Z

:Matthew Dillon wrote:
:> 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.
:
:Stephen's point is that there are applications which use mprotect() on a
:per-page basis. Some garbage collectors for example, to track dirtied
:pages.
:
:And having to scan hundreds of vmas to find one pte sucks :-)
:
:But I addressed that a few minutes ago. In my scheme you don't have to
:scan lots of vmas to find that pte. Only one or two, or you can choose
:to increase that number while decreasing memory requirements a little.
:
:-- Jamie

Hmm. I know apps which use madvise() to manage allocated/free pages
efficiently, but not any that use mprotect(). The madvise() flags
typically used effect the underlying pages directly and should not fragment
the VMA's at all. In anycase, it's not a big deal because even if you
did have to fragment the VMA's, you can still collapse adjacent entries
together. i.e. if the garbage collector protects page 1 and then later
on protects page 2 the same way, you still need only one VMA to
represent both pages.

-Matt
Matthew Dillon
<dillon@backplane.com>