Maximum bootable kernel size in current ARM linux

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Thu, Sep 16, 2010 at 06:16:51PM +0100, Catalin Marinas wrote:
> On Tue, 2010-09-14 at 13:37 -0400, Nicolas Pitre wrote:
> > On Tue, 14 Sep 2010, Catalin Marinas wrote:
> > 
> > > I think the Thumb-2 branch goes up to 16MB range. The Thumb-1 may be
> > > smaller but we don't support this in the kernel. That's why Thumb-2
> > > modules are within 8MB below PAGE_OFFSET. But this leaves us with
> > > maximum 8MB of kernel size.
> > 
> > Hmmm.  Would be worth moving the pkmap area below modules then.
> 
> So currently the pkmap area is at PAGE_OFFSET - 2MB. On a Thumb-2 kernel
> with highmem enabled we would have 6MB available to modules. Is this big
> enough? If not, we could move the pkmap area.
> 
> BTW, can it be moved in the top part of the memory rather than below
> PAGE_OFFSET?

If you move it to the top part of memory, then it'll be about (sizeof
low memory) bytes - 32K away from the kernel code - which means it'll
mostly always be outside of the PC relative relocation range.

Indirecting all PC relative branches through trampolines quickly becomes
expensive, not only on CPUs which don't do branch prediction, but also
because of the mixed up code and data.

What might make sense is to move the init stuff between the kernel code
and kernel data - but that leads to a penalty of possibly 8 to 16K of
wasted space in the kernel image (for section alignment.)

I think we're better of staying as we are - thereby keeping the performance
for the majority use case, and telling those few people who want a massive
kernel binary not to do that.  In the case of a large initramfs, pass it
in as an initrd, possibly using the bootp stuff I've mentioned previously
if you want a single self-contained image.