Subject: Re: pmap layer inefficiencies, and possible solutions
To: None <neil@causality.com>
From: Charles M. Hannum <root@ihack.net>
List: tech-kern
Date: 12/08/1998 08:33:29
I considered doing what you suggest (a second per-pmap list). Indeed,
if such a list were present, we could almost (but not quite, due to
msync(2)) get rid of pv_lists. However, I don't think it's a good
solution for several reasons:
1) It *only* helps in the very specific case of process exit; it
doesn't help for *any* other case where pages are unmapped --
including munmap(2), shmdt(2), or execve(2). While the exit case
is certainly important, it does not require *quite* that much
special attention. The changes I proposed should help in all of
these cases.
It's also not all that efficient even for the exit case, because
(as should be apparent) it still has no locality of reference and
therefore will thrash the TLB (and the cache).
2) It actually makes the pv_lists larger and more complex to maintain
in all other cases. My proposal only slows down pv_list walks
(which would now only be done while scanning pages for inactivation
or pageout -- already a complex GC pass) by adding an extra test,
which will only trigger if there are stale entries. Plus an
occasional GC pass over the pv_lists.
It also occurs to me that this rare GC pass could also be an
opportunity to coalesce entries for the same page, thereby further
increasing efficiency in the future.
So, it seems to me that my lazy deletion algorithm should be much more
effective overall.