![]() | |||||||||||
Messages in this thread Complete thread (EXPERIMENTAL) |
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? 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 :-) Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca - 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/ | ||||||||||
![]() | |||||||||||
| Last update: 2005-03-22 12:15 [W:0.550 / U:0.280 seconds] ©2003-2005 Jasper Spaans | |||||||||||