[lkml]   [2012]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH -mm 2/2] mm: do not reset mm->free_area_cache on every single munmap
On 02/23/2012 04:56 PM, Andrew Morton wrote:
> On Thu, 23 Feb 2012 15:00:34 -0500
> Rik van Riel<> 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

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

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

 \ /
  Last update: 2012-02-27 17:15    [W:0.049 / U:3.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site