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
-
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 : Tue Oct 15 2002 - 22:00:57 EST