Re: [PATCH -mm 2/2] mm: do not reset mm->free_area_cache on everysingle munmap

[Rik van Riel]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/