From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14132 invoked by alias); 10 Oct 2011 13:54:24 -0000 Received: (qmail 14112 invoked by uid 22791); 10 Oct 2011 13:54:22 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 Oct 2011 13:54:06 +0000 Received: by one.firstfloor.org (Postfix, from userid 503) id 8D9751A9808B; Mon, 10 Oct 2011 15:54:05 +0200 (CEST) Date: Mon, 10 Oct 2011 14:04:00 -0000 From: Andi Kleen To: Jakub Jelinek Cc: Richard Guenther , Andi Kleen , gcc-patches@gcc.gnu.org, Andi Kleen Subject: Re: [PATCH 3/5] On a Linux kernel ask explicitely for a huge page in ggc Message-ID: <20111010135405.GW14482@one.firstfloor.org> References: <1318190141-1220-1-git-send-email-andi@firstfloor.org> <1318190141-1220-4-git-send-email-andi@firstfloor.org> <20111010102903.GW19412@tyan-ft48-01.lab.bos.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111010102903.GW19412@tyan-ft48-01.lab.bos.redhat.com> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00770.txt.bz2 On Mon, Oct 10, 2011 at 12:29:03PM +0200, Jakub Jelinek wrote: > On Mon, Oct 10, 2011 at 12:15:14PM +0200, Richard Guenther wrote: > > On Sun, Oct 9, 2011 at 9:55 PM, Andi Kleen wrote: > > > From: Andi Kleen > > > > > > Benchmarks show slightly faster build times on a kernel > > > build, near the measurement error unfortunately. > > > > > > This will only work with a recent glibc that defines MADV_HUGEPAGE. > > > > Will partial unmaps fail or split the page? > > I think it will not do anything, because with G.pagesize * GGC_QUIRE_SIZE On large builds (LTO) I see the vmstat THP counter increasing, it doesn't do too much on small builds. > being just 2MB (and most likely not 2MB aligned either) it would do > something only if it happens to be 2MB aligned or the following VMA > is also MADV_HUGEPAGE hinted and no pages in the 2MB region have been > paged in yet. > So, either we need to ensure that the address is likely 2MB aligned, > or use on x86_64 even bigger GGC_QUIRE_SIZE (such as 16MB or 32MB) and > then huge pages would be likely used at least for the aligned inner > huge pages in the region. Hmm, that gets too complicated for mee. I'll drop the patch for now. It's not strictly needed to fix the fragmentation problem and it's also possible to force THP from the kernel. -Andi -- ak@linux.intel.com -- Speaking for myself only.