Andrea Arcangeli <andrea@suse.de> wrote:
>
> Indeed. objrmap is the only way to avoid the big rmap waste. Infact I'm
> not even convinced about the hybrid approch, rmap should be avoided even
> for the anon pages. And the swap cpu doesn't matter, as far as we can
> reach pagteables in linear time that's fine, doesn't matter how many
> fixed cycles it takes. Only the complexity factor matters, and objrmap
> takes care of it just fine.
Well not really.
Consider the case where 100 processes each own 100 vma's against the same
file.
To unmap a page with objrmap we need to search those 10,000 vma's (10000
cachelines). With full rmap we need to search only 100 pte_chain slots (3 to
33 cachelines). That's an enormous difference. It happens for *each* page.
And, worse, we have the same cost when searching for referenced bits in the
pagetables. Nobody has written an "exploit" for this yet, but it's there.
Possibly we should defer the assembly of the pte chain until a page hits the
tail of the LRU. That's an awkward time to be allocating memory though. We
could perhaps fall back to the vma walk if pte_chain allocation starts to
endanger the page reserves.
-
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/
This archive was generated by hypermail 2b29 : Mon Apr 07 2003 - 22:00:25 EST