This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-07 08:25:37 UTC ---
(In reply to comment #4)
> Right now alloc_page will (usually) allocate in GGC_QUIRE_SIZE * G.pagesize
> chunks, but release_pages will munmap individual pages immediately during
> collection (well, using one munmap if there are consecutive free pages, but
> that is not very likely everything is going to be freed from the whole 1MB
> page).
> Guess we could do MADV_DONTNEED on the individual pages immediately and if we
> have consecutive 1MB region all free, munmap it (or, decide about that based on
> how many free pages we have etc.).  I guess doubling GGC_QUIRE_SIZE is
> reasonable too.

I guess that's a good idea, separate from the 2mb page issue.  Do other systems
beside Linux have MADV_DONTNEED?  I suppose popular host platforms include
Windows and Mac OS today.

It also seems that we release pages we put on the free list when allocating
a GGC_QUIRE_SIZE * G.pagesize chunk (which we only do if we allocate exactly
one page, otherwise we map a random amount of memory).  Would probably be
interesting to add some instrumentation code to see how the map/munmap
patterns look like ...

But yes, it seems we should unmap only in groups but advise in smaller chunks.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]