Nuno Lucas wrote:
On 4/18/06, Christian Smith <[EMAIL PROTECTED]> wrote:

The OS has to track each MMAP segment, which is usually a linear linked
list sorted by virtual address. As most processes don't have that many
segments mapped (10's of segments would be considered a lot) the O(n)
linear search is not considered much of a burden. If this increases to the
100's or 1000's of segments, the kernel will spend correspondingly more
time in VM management. Such linear searches can also have a detrimental
effect on the CPU caching.


Modern OSs use binary trees (rb-trees or the like) to manage memory
maps (linux has an rb-tree and also a linked list), so it's not a
linear search.

Also, as all modern OSs use paging everywhere, they tend to use
"mmaping" internally for every file access (on devices that support
it, off course). The "mmap" paradigm fits best with the paging system
than the old buffer aproach, allowing lot's of "neat" tricks, like
demand paging, lazy writes, copy on write, etc.

Windows internally uses sections (the kernel equivalent of mmaps) for
all file accesses, with the diference those sections of the file are
dynamic for sequential/random file access (iirc, 256KB view blocks)
and fixed when user explicitly mmaps a file (creates a file view).

I believe Linux also does it (for block devices which support mmap),
but I don't know the details.

10's of segments is not a lot, if you remember all DLLs are also
mmaped, specially on big GUI applications made with very high level
languages.

Off course there will be an overhead when using a LOT of mmaped files,
but that will be mainly because of the increased memory need,
affecting caching and paging, two of the most big factors for
performance levels, but not a direct relation as there are ways to
fight it (eg, maximize cache locality).


Best regards,
~Nuno Lucas
Thanks, Nuno. That is extremely helpful. You confirm what one would intuitively expect, that staying at the VM level in your program and avoiding the read/write level layered over it is a good strategy. I shall follow it.
JS

Reply via email to