On Sun, Oct 23, 2011 at 12:23 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > 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?
I wonder if the free list that falls out of a single collection is sorted (considering also ggc_free) - if it is, building a new one at each collection and then merging the two sorted lists should be reasonably fast. >> >>> 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 >> >
