Re: [Fastboot] [CFT] ELF Relocatable x86 and x86_64 bzImages

From: Jan Kratochvil <lace@jankratochvil.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: vgoyal@in.ibm.com, fastboot@osdl.org, Horms <horms@verge.net.au>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Magnus Damm <magnus.damm@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Fastboot] [CFT] ELF Relocatable x86 and x86_64 bzImages
Date: Tue, 1 Aug 2006 11:43:51 +0200	[thread overview]
Message-ID: <20060801094351.GA25944@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <m1bqr43jqv.fsf@ebiederm.dsl.xmission.com>

On Tue, 01 Aug 2006 11:09:28 +0200, Eric W. Biederman wrote:
> Jan Kratochvil <lace@jankratochvil.net> writes:
...
> > i386 had alignment requirement:
> > 	/* current_thread_info()&co. are 8192-alignment fixed (for the initial
> > stack). */
> > 	#if CONFIG_PHYSICAL_START & 0x1FFF
> > 	#error "CONFIG_PHYSICAL_START must be 2*PAGE_SIZE (0x2000) aligned!"
> > 	#endif
> > as IIRC those i386 2MB/4MB pages must be (apparently) 2MB/4MB aligned in the
> > virtual address space but their physical target address can be arbitrary.
> 
> I know you can't use huge pages if your physical address is not
> properly aligned.   Which can be a performance impact if nothing else.
> Not something I want to encourage in a general purpose kernel. 

So you rather crash than running in that unmeasurably lower performance?

IIRC those 2MB/4MB pages performance "gain" is still present (in my patch)
even if the kernel location is not 2MB/4MB aligned because the i386 2MB/4MB
pagetable entries can have arbitrary physical memory target address.
But maybe I lie here, sorry, I really do not remember it much.
(It 100% worked with the "full performance" if aligned and it "worked" if
unaligned but I do not remember if it worked "full performance" if unaligned.)

...
> I'm not terribly comfortable with the 8K alignment number as we only
> tell the linker we need 4K alignment.

Yes, it should be fixed there so that the stacks get allocated 8KB-aligned not
depending on the kernel code position at all.  That means allocating the
initial stack by code and not relying on its autoallocation by the linker.
There would remain the 4KB alignment requirement due to the physical target
address of the pagetable entries.

...
> > ( I did not check your patches as they are locked in that useless GIT anyway. )
> ( As opposed to the unuseable CVS I presume :)

Yes, it has the same unusability as CVS, just it looses the feature of being
the standard.  I assume some CVS flamewar already occured some time ago.

Regards,
Lace