> 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
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()
- move architecture-specific magic to <asm/pmap.h> so it's now
easy to port to other architectures (yes, this stuff is all
-- IA64: a worthy successor to i860.
Send all your spam to firstname.lastname@example.org (spam digging piggy)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/