Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932255AbWHCEyV (ORCPT ); Thu, 3 Aug 2006 00:54:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932268AbWHCEyV (ORCPT ); Thu, 3 Aug 2006 00:54:21 -0400 Received: from terminus.zytor.com ([192.83.249.54]:23960 "EHLO terminus.zytor.com") by vger.kernel.org with ESMTP id S932255AbWHCEyU (ORCPT ); Thu, 3 Aug 2006 00:54:20 -0400 Message-ID: <44D1815C.1040508@zytor.com> Date: Wed, 02 Aug 2006 21:53:48 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: "Eric W. Biederman" CC: Don Zickus , fastboot@osdl.org, Horms , Jan Kratochvil , Magnus Damm , linux-kernel@vger.kernel.org Subject: Re: [Fastboot] [RFC] ELF Relocatable x86 and x86_64 bzImages References: <20060802183709.GJ3435@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1706 Lines: 45 Eric W. Biederman wrote: > Don Zickus writes: > >>> There is one outstanding issue where I am probably requiring too much >> alignment >>> on the arch/i386 kernel. >> There was posts awhile ago about optimizing the kernel performance by >> loading it at a 4MB offset. >> >> http://www.lkml.org/lkml/2006/2/23/189 >> >> Your changes breaks that on i386 (not aligned on a 4MB boundary). But a >> 5MB offset works. Is that the correct update or does that break the >> original idea? > > That patch should still apply and work as described. > > Actually when this stuipd cold I have stops slowing me down, > and I fix the alignment to what it really needs to be ~= 8KB. > > Then bootloaders should be able to make the decision. > > HPA Does that sound at all interesting? > I'm sorry, it's not clear to me what you're asking here. The bootloaders will load bzImage at the 1 MB point, and it's up to the decompressor to locate it appropriately. It has (correctly) been pointed out that it would be faster if the decompressed kernel is located to the 4 MB point -- large pages don't work below 2/4 MB due to interference with the fixed MTRRs -- but that's doesn't affect the boot protocol in any way. I was under the impression that your relocatable patches allows the boot loader to load the bzImage at a different address than the usual 0x100000; but again, that shouldn't affect the kernel's final resting place. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/