> Rik while you are looking at your reverse mapping code, I would like
> to call to your attention the at least trippling of times for fork.
Dave McCracken has measured this on his system, it seems to vary
from between 10% for bash to 400% for a process with 10 MB of memory.
This is a problem which will need to be solved, a number of designs
on how to deal with this are ready, implementation needs to be done.
> I wouldn't be surprised if the reason your rmap vm handles things like
> gcc -j better than the stock kernel is simply the reduced number of
> processes, due to slower forking.
I really doubt this, since gcc spends so much more time doing
real work than forking that the time used in fork can be ignored,
even if it gets 3 times slower.
> Just my 2 cents so we don't forget the caveats of the reverse map
> approach.
The main way we can speed up fork easily is by not copying the
page tables at all at fork time but filling them in later at page
fault time. While this might look like it's just moving the overhead
from one place to another, but for the typical fork()+exec() case it
means (1) we don't copy the page tables at fork time (2) we don't
need to free them at exec time (3) after the exec, the parent can
just take back the complete page tables without having to take COW
faults on all its pages.
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/