> It's nice to see these tests aren't running any slower (and not
> crashing!) but as I understand it, reverse mapping is a win only for
> shared mmaps and swapping, which you aren't doing. So it's not clear
> what effect is being measured.
For one, with this thing we can actually "see" the referenced
bits in the page tables from refill_inactive(), so page aging
could potentially be better.
Samium's numbers, showing how much better, were a tad surprising
to me too, though ;)
> One thing that goes away with rmaps is the need to scan process page
> tables. It's possible that this takes enough load off L1 cache to
> produce the effects you showed, though it would be surprising.
CPU overhead seems to be a bit lower in the tests I ran, where
"a bit" should mostly be significant in the case of many shared
pages.
The real savings should be better pageout selection and lots of
flexibility to do interesting things, though.
> (Note that I'm in the "reverse maps are good" camp, and I think Rik's
> design is fundamentally correct.)
Btw, I just released a new version of the patch, which:
- moves page_remove_pmap() one line down in mremap(), so it
works now ;)
- starts making the reverse mapping patch SMP safe, removing
try_to_swap_out() and replacing it by allocate_swap_space()
and try_to_unmap()
- move architecture-specific magic to <asm/pmap.h> so it's now
easy to port to other architectures (yes, this stuff is all
documented)
http://www.surriel.com/patches/2.4/2.4.8-ac12-pmap3
regards,
Rik
-- IA64: a worthy successor to i860.http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to aardvark@nl.linux.org (spam digging piggy)
- 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/