Re: [patch] mmap-speedup-2.5.42-C3

[Andi Kleen <ak@muc.de>]

Andrew Morton <akpm@digeo.com> writes:

> Yup.  We'd need to be able to perform a search based on "size of hole"
> rather than virtual address.  That really needs a whole new data structure
> and supporting search code, I think...  It also may have side effects
> to do with fragmentation of the virtual address space.

When you oprofile KDE startup you notice that a lot of time is spent in
get_unmapped_area too. The reason is that every KDE process links with
10-20 libraries and ends up with a 40-50 entry /proc/<pid>/maps.

Optimizing this case would be likely useful too, although I suspect
Ingo's last hit cache would already help somewhat.

When you add a funky data structure please trigger it on the number
of mappings at least. e.g. I bet a micro optimized (= uses prefetch) 
single linked list or even array will be always best for <= 10 entries,
which is still not that uncommon in the non KDE world.

Array would be attractive because you can trivially prefetch it,
but would eat more space per mm_struct. Assuming each process has at 
least 5 mappings the cost should be rather small though.

-Andi