Re: [PATCH 2/2] arm: fix kernel image size

[Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>]

On Tue, Jun 21, 2016 at 09:55:25AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [160621 08:46]:
> > On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote:
> > > 
> > > Maybe zImage size + MAX_RODATA_SZ + 4x zImage size?
> > > 
> > > Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we
> > > think is sufficient to kick the can until we have a better
> > > solution.
> > 
> > Maybe if you give some details about your failing case - you omitted any
> > details about the uncompressed image size...
> 
> Looks like we currently have this:
> 
> Memory: 2033088K/2095100K available (7376K kernel code, 784K rwdata,
> 2312K rodata, 1024K init, 8117K bss, 45628K reserved,
> 16384K cma-reserved, 1292284K highmem)
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
>     vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
>     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
>     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
>     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
>       .text : 0xc0008000 - 0xc0a762a4   (10681 kB)
>       .init : 0xc0b00000 - 0xc0c00000   (1024 kB)
>       .data : 0xc0c00000 - 0xc0cc411c   ( 785 kB)
>        .bss : 0xc0cc6000 - 0xc14b37f8   (8118 kB)

So that's 20.7MB, and the zImage was 3.6MB.  You're getting an
expansion ratio of 5.7x.

To fix that, we'd need to up it to 7x, but the problem with upping
it in this way is that it increases the requirements for the
crashdump region too.  We can play with this number, but there will
always be cases where it doesn't work - either because the ratio is
too big or too small.

By way of illustration, "zImage size + MAX_RODATA_SZ + 4x zImage size"
doesn't even work for this case, since you need about 25MB.  Your
calculation comes out at 22MB, which is 3MB short.  Not only that, but
it introduces (from what I can see) an irrelevant fudge factor of
"MAX_RODATA_SZ" which has no basis in what's really going on here, and
I'm left wondering what "MAX_RODATA_SZ" is actually referring to.

So... I'm of the opinion that we shouldn't play with it - but instead
try to come up with a solution which *doesn't* involve teaching kexec
a whole load of internals about how the ARM kernel booting happens.

What's more worrying to me at the moment, though, is that the kexec code
only tries to find memory for the actual "kernel" size, not the actual
space required to decompress the kernel.  It could find a chunk of
memory large enough to fit the kernel image to be loaded, but is not big
enough to allow its decompression.  kexec is really quite a mess on
ARM. :(

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.