On 21 Jan 2002, Eric W. Biederman wrote:
> Currently the rmap patch triples the size of the page tables which is
> also an issue. Though it is relatively straight forward to reduce
> that to simply double the page table size with a order(1) allocation,
> so we can remove one pointer.
Actually most processes seem to be much smaller than 4 MB
_and_ have their pages spread out over their address space.
This means the page tables are sparsely populated and the
pte_chain mechanism should use less memory than doubling
the size of the page tables.
> Unless I am mistaken an every day shell script is fairly fork/exec/exit
> intensive operation. And there are probably more shell scripts for
> unix than every other kind of program put together.
Bash and gcc seem to use vfork, not sure about make...
> An additional possible strike against rmap is that walking through
> page tables in virtual address order is fairly cache friendly, while a
> random walk has more of a cache penalty.
In theory. In practice however kswapd seems to use less CPU
with the -rmap VM, most notably in doesn't seem to get lost
in the worst case behaviour of the normal VM where it scans
hundreds of megabytes of normal memory because it has a DMA
zone shortage...
> One more case that is difficult for rmap is the highly mapped case of
> something like glibc. You can easily get to a thousand entries or
> more for a single page. In which case a doubly linked list may be
> more appropriate then a singly linked list (for add/insert), but this
> again tripples or quadruples the page table size. And none of it
> solves having to walk very long lists in some circumstances. The
> best you can do is periodically unmapping pages, and then you only
> have very long lists for highly active pages.
I admit this could be an issue. It would be interesting to see
if it is an issue in practice though...
> And to be fair rmap has some advantages over the current system. VM
> algorithms are some simpler to code when you can code them however
> you want to, instead of being constrained by other parts of the
> implementation.
>
> To the true sceptic what remains to be shown is
Well, you could download the patch and look for yourself ;)
http://surriel.com/patches/
http://linuxvm.bkbits.net/
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 23 2002 - 21:00:44 EST