On Sun, Oct 16, 2011 at 12:38:16PM +0200, Richard Guenther wrote: > On Sun, Oct 16, 2011 at 7:30 AM, Andi Kleen <a...@firstfloor.org> wrote: > > Andi Kleen <a...@firstfloor.org> writes: > > > >> From: Andi Kleen <a...@linux.intel.com> > >> > >> Use the Linux MADV_DONTNEED call to unmap free pages in the garbage > >> collector.Then keep the unmapped pages in the free list. This avoid > >> excessive memory fragmentation on large LTO bulds, which can lead > >> to gcc bumping into the Linux vm_max_map limit per process. > > > > Could I have a decision on this patch please? The problem in PR50636 > > is still there and this is the minimum fix to fix it on Linux > > as far as I know. > > > > If this patch is not the right way to go I would > > appreciate some guidance on an alternative (but low cost) > > implementation. Note I don't have capacity for any overly > > complicated solutions. > > The patch looks generally ok, but you are never giving back pages to the
It gives back pages, just not virtual address space. But I guess that is what you meant. On the other hand this patch can actually give you more virtual address space when you need large regions (>2 pages or so). The reason is that the old allocation pattern fragments the whole address space badly and only leaves these small holes. With the madvise patch that does not happen, ggc is all in a compacted chunk. > system, and as we have other memory allocations that do not use the > ggc pools you drain virtual memory on 32bit hosts. Is any other patch > in this series compensating for it? If not I'd say we should munmap the > pages when a full mapped range (2MB) is free. Can you rename I wrote such a patch initially, but ran into various problems, so I dropped it from the series. I can revisit it. > 'unmapped' to 'discarded' please? That would be less confusing. Ok I can do that. Was that an approval? -Andi
