On Fri, Oct 21, 2011 at 8:30 PM, Andi Kleen <a...@firstfloor.org> wrote: >> > diff --git a/gcc/ggc-page.c b/gcc/ggc-page.c >> > index ba88e3f..eb0eeef 100644 >> > --- a/gcc/ggc-page.c >> > +++ b/gcc/ggc-page.c >> > @@ -972,6 +972,54 @@ release_pages (void) >> > page_entry *p, *start_p; >> > char *start; >> > size_t len; >> > + size_t mapped_len; >> > + page_entry *next, *prev, *newprev; >> > + size_t free_unit = PARAM_VALUE (GGC_FREE_UNIT) * G.pagesize; >> > + >> > + /* First free larger continuous areas to the OS. >> > + This allows other allocators to grab these areas if needed. >> > + This is only done on larger chunks to avoid fragmentation. >> > + This does not always work because the free_pages list is only >> > + sorted over a single GC cycle. */ >> >> But release_pages is only called from ggc_collect, or what do you > > If there was a spike in GC usage and we end up with lots of free > space in the free list afterward we free it back on the next GC cycle. > Then if there's a malloc or other allocator later it can grab > the address space we freed. > > That was done to address your earlier concern. > > This will only happen on ggc_collect of course. > > So one difference from before the madvise patch is that different > generations of free pages can accumulate in the freelist. Before madvise > the freelist would never contain more than one generation. > Normally it's sorted by address due to the way GC works, but there's no > attempt to keep the sort order over multiple generations. > > The "free in batch" heuristic requires sorting, so it will only > work if all the pages are freed in a single gc cycle. > > I considered sorting, but it seemed to be too slow. > > I can expand the comment on that.
Ah, now I see ... but that's of course bad - I expect large regions to be free only after multiple collections. Can you measure what sorting would make for a difference? > >> mean with the above? Would the hitrate using the quire size increase >> if we change how we allocate from the freelist or is it real fragmentation >> that causes it? > > Not sure really about the hitrate. I haven't measured it. If hitrate > was a concern the free list should be probably split into an array. > I'm sure there are lots of other tunings that could be done on the GC, > but probably not by me for now :) Heh. Yeah, I suppose the freelist could be changed into a list of allocation groups with free pages and a bitmap. Richard. >> >> I'm a bit hesitant to approve the new param, I'd be ok if we just hard-code >> quire-size / 2. > > Ok replacing it with a hardcoded value. > > -Andi >
