From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32504 invoked by alias); 26 May 2006 14:00:53 -0000 Received: (qmail 32454 invoked by uid 22791); 26 May 2006 14:00:53 -0000 X-Spam-Check-By: sourceware.org Received: from smtp105.sbc.mail.mud.yahoo.com (HELO smtp105.sbc.mail.mud.yahoo.com) (68.142.198.204) by sourceware.org (qpsmtpd/0.31) with SMTP; Fri, 26 May 2006 14:00:14 +0000 Received: (qmail 53378 invoked from network); 26 May 2006 13:58:37 -0000 Received: from unknown (HELO lucon.org) (hjjean@sbcglobal.net@71.146.96.173 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 26 May 2006 13:58:36 -0000 Received: by lucon.org (Postfix, from userid 1000) id C6584641B3; Fri, 26 May 2006 06:58:35 -0700 (PDT) Date: Sat, 27 May 2006 16:33:00 -0000 From: "H. J. Lu" To: Nick Clifton , binutils@sources.redhat.com, discuss@x86-64.org Subject: Re: PATCH: Change x86-64 maximum page size to 2MB Message-ID: <20060526135835.GA21942@lucon.org> References: <20060516232326.GA18996@lucon.org> <446D8BE1.3030504@redhat.com> <20060525231019.GA16017@lucon.org> <20060526024303.GA16636@nevyn.them.org> <20060526030324.GA17436@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060526030324.GA17436@lucon.org> User-Agent: Mutt/1.4.2.1i Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00479.txt.bz2 On Thu, May 25, 2006 at 08:03:25PM -0700, H. J. Lu wrote: > On Thu, May 25, 2006 at 10:43:03PM -0400, Daniel Jacobowitz wrote: > > On Thu, May 25, 2006 at 04:10:19PM -0700, H. J. Lu wrote: > > > On Fri, May 19, 2006 at 10:12:01AM +0100, Nick Clifton wrote: > > > > Hi H. J. > > > > > > > > >The current x86-64 maximum page size is 1MB. With the future > > > > >development, 2MB is better for performance. Using 2MB won't break > > > > >anything, except for up to 2MB gap in virtual address space per file, > > > > >instead of 1MB. x86-64 has 48 bits in virtual address space. It > > > > >shouldn't be an issue for most applications. I have a patch: > > > > > > > > > >http://sourceware.org/ml/binutils/2005-05/msg00644.html > > > > > > > > > >which can be used to implement "-z max-page-size=xxxx" so that people > > > > >can control maximum page size at the link time if they prefer different > > > > >maximum page size. > > > > > > > > This seems to be perfectly reasonable. > > > > > > I tested this patch on gcc, glibc, 2.4 and 2.6 kernels. I will check > > > it in shortly. > > > > If you do this without setting ELF_MINPAGESIZE, won't BFD start to > > reject some files? > > > > It doesn't happen obviously, they'll just get corrupted on objcopy; > > see the one use of ->minpagesize. > > > > Thanks. I am checking in this patch. I will add a testcase once we can > use a different maximum page size. > > Linux/x86-64 supports 4K page size. I am changing ELF_MINPAGESIZE to 4K. H.J. 2006-05-26 H.J. Lu * elf64-x86-64.c (ELF_MINPAGESIZE): Changed to 0x1000. --- bfd/elf64-x86-64.c.4k 2006-05-26 06:54:45.000000000 -0700 +++ bfd/elf64-x86-64.c 2006-05-26 06:55:31.000000000 -0700 @@ -3631,7 +3631,7 @@ static const struct bfd_elf_special_sect #define ELF_ARCH bfd_arch_i386 #define ELF_MACHINE_CODE EM_X86_64 #define ELF_MAXPAGESIZE 0x200000 -#define ELF_MINPAGESIZE 0x100000 +#define ELF_MINPAGESIZE 0x1000 #define elf_backend_can_gc_sections 1 #define elf_backend_can_refcount 1