On 02/23/2012 04:56 PM, Andrew Morton wrote:
On Thu, 23 Feb 2012 15:00:34 -0500
Rik van Riel<riel@xxxxxxxxxx> wrote:
The benefit is that things scale a lot better, and we remove about
200 lines of code.
We've been playing whack-a-mole with this search for many years. What
about developing a proper data structure with which to locate a
suitable-sized hole in O(log(N)) time?
I have thought about this, and see a few different
possibilities:
1) Allocate a new (smaller) structure to keep track
of free areas; this creates the possibility of
munmap failing due to a memory allocation failure.
It looks like it can already do that, but I do not
like the idea of adding another failure path like
it.
2) Use the vma_struct to keep track of free areas.
Somewhat bloated, and may still not fix (1), because
munmap can end up splitting a VMA.
I guess the free areas could be maintained in a prio tree,
sorted by both free area size and address, so we can fill
in the memory in the desired direction.
What I do not know is whether it will be worthwhile,
because the code I have now seems to behave well even
what is essentially a worst case scenario.
--
All rights reversed
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>