From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-369643-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30593 invoked by alias); 6 Oct 2011 21:42:05 -0000
Received: (qmail 30582 invoked by uid 22791); 6 Oct 2011 21:42:04 -0000
X-SWARE-Spam-Status: No, hits=-2.9 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 06 Oct 2011 21:41:42 +0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
Date: Thu, 06 Oct 2011 21:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-50636-4-9QjwEFNmKg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-50636-4@http.gcc.gnu.org/bugzilla/>
References: <bug-50636-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2011-10/txt/msg00387.txt.bz2

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-10-06 21:41:41 UTC ---
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.