Messages in this thread | | | Date | Mon, 27 Feb 2012 11:12:42 -0500 | From | Rik van Riel <> | Subject | Re: [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<riel@redhat.com> 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
| |