Re: Linux 2.4.18pre3-ac1

[Daniel Phillips <phillips@bonn-fries.net>]

On January 21, 2002 06:30 am, Richard Gooch wrote:
> Daniel Phillips writes:
> > The way I see it, the purpose of lazy page table instantiation is to
> > overcome objections to the reverse pte mapping vm technique that
> > have been expressed in the past, namely the slowdown in dup_mmap
> > inside fork.  I.e., if rmap slows down fork then Linus and Davem are
> > going to veto it, as they've done in the past, because they feel
> > that the as-yet-unproven advantages of physically-based vm scanning
> > doesn't outweigh the easily measurable fork overhead.  Personally, I
> > think that's debatable, but by eliminating the overhead we eliminate
> > the objection, and as far as I know, it's the only serious
> > objection.
> 
> Will lazy page table instantiation speed up fork(2) without rmap?

Yes.

> If so, then you've got a problem, because rmap will still be slower
> than non-rmap. Linus will happily grab any speedup and make that the
> new baseline against which new schemes are compared :-)

Fortunately, rmap and non-rmap will fork at the same speed since in
each case the work will consist of copying just the page directory and
incrementing the use counts of up to 1024 page tables.

Page table instantiation, which happens at fault time, will be slower
for rmap than non-rmap.  However there are offsetting factors that
suggest the bottom line performance will be very similar in unloaded
cases, and will favor rmap under heavy load.

--
Daniel