This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 07 Oct 2011 08:25:37 +0000
- Subject: [Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
- Auto-submitted: auto-generated
- References: <bug-50636-4@http.gcc.gnu.org/bugzilla/>
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.