Re: Benchmarking objrmap under memory pressure

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Apr 14, 2004 at 06:48:40PM +0100, Hugh Dickins wrote:
> This is just your guess at present, isn't it, Andrea?  Any evidence?

the evidence is pretty obvious, the single fact it's painful to remove
the page_table_lock with anonmm around the vma manipulations, and the
little benefit that the vma->page_table_lock provides with anonmm is
quite a tangible measurements, I'm talking about the 256 ways here, any
UP measurements is pretty useless.

Last but not the least, you cannot know if any important app is going to
be hurted with mremap doing copies and invalidating important
optimizations for any application doing similar things that kde is doing
to save memory and speedup startup times (we don't even know yet if kde
itself is going to be hurted), you can take these risks with mainline, I
cannot risk with -aa, and anon-vma provides other minor benefits too
that we already discussed plus the IMHO important scalability point above.

So I don't see why should mainline go with an inferior solution when
I've already sorted out a better one.