Messages in this thread | | | Date | Sat, 5 Apr 2003 13:24:06 -0800 | From | Andrew Morton <> | Subject | Re: objrmap and vmtruncate |
| |
Andrea Arcangeli <andrea@suse.de> wrote: > > On Sat, Apr 05, 2003 at 04:06:14AM -0800, Andrew Morton wrote: > > Andrew Morton <akpm@digeo.com> wrote: > > > > > > Nobody has written an "exploit" for this yet, but it's there. > > > > Here we go. The test app is called `rmap-test'. It is in ext3 CVS. See > > > > http://www.zip.com.au/~akpm/linux/ext3/ > > > > It sets up N MAP_SHARED VMA's and N tasks touching them in various access > > patterns. > > I'm not questioning during paging rmap is more efficient than objrmap, > but your argument about rmap having lower complexity of objrmap and that > rmap is needed is wrong. The fact is that with your 100 mappings per > each of the 100 tasks case, both algorithms works in O(N) where N is > the number of the pagetables mapping the page.
Nope. To unmap a page, full rmap has to scan 100 pte_chain slots, which is 3 cachelines worth. objrmap has to scan 10,000 vma's, 9,900 of which do not map that page at all.
(Actually, there's a recent optimisation in objrmap which will on average halve these figures).
> And objrmap can't avoided, it's needed for the truncate semantics > against mmap.
What do you mean by this? vmtruncate continues to use the 2.4 algorithm for that.
> Check all other important benchmarks not testing the paging load like > page faults, kernel compile from Martin, fork, AIM etc... Those are IMHO > an order of magnitude of more interest than your rmap-test paging load > with some hundred thousand of vmas.
Andrea, I whine about rmap as much as anyone ;) I'm the guy who halved both its speed and space overhead shortly after it was merged.
But the fact is that it is not completely useless overhead. It provides a very robust VM which is stable and predictable under extreme and unusual loads. That is valuable.
Yes, rmap adds a few% speed overhead - up to 10% for things which are admittedly already very inefficient.
objrmap will reclaim a lot of that common-case overhead. But the cost of that is apparently unviability for certain workloads on certain machines. Once you hit 100k VMA's it's time to find a new operating system.
Maybe that is a tradeoff we want to make. I'm adding some balance here.
The space consumption of rmap is a much more serious problem than the speed overhead. It makes some workloads on huge ia32 machines unviable.
Me, I have never seen any evidence that we need any of it. I have never seen a demonstration of the alleged failure modes of 2.4's virtual scan. But then I haven't tried very hard.
The extreme stability and scalability of full rmap is good. The space consumption on highmem is bad. The CPU cost is much less important than these things.
- 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/
| |