linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] arm: fix kernel image size
Date: Wed, 22 Jun 2016 00:36:16 -0700	[thread overview]
Message-ID: <20160622073614.GZ22406@atomide.com> (raw)
In-Reply-To: <20160621215141.GC5783@n2100.arm.linux.org.uk>

* Russell King - ARM Linux <linux@armlinux.org.uk> [160621 14:54]:
> 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.

OK

> 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.

Well I thinking the section alignment split might give us some
known size for rodata, but looking at it more it's only with
DEBUG_ALIGN_RODATA. If we can't make any assumptions about the
size of the rodata, then no point adding it.

> 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. :(

How about we check the size of RAM available, and if there is plenty
of RAM we use a safe compression ratio of 8. If RAM is a problem,
we could make the compression ratio smaller and warn about it. And
we could also allow passing the compression ratio to kexec as an
option.

I forgot if we still have some 128MB limits too..

Regards,

Tony

  reply	other threads:[~2016-06-22  7:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-17 19:44 [PATCH 0/2] Simple fix to the ARM kexec tools implementation Russell King - ARM Linux
2016-06-17 19:44 ` [PATCH 1/2] arm: take account of TEXT_OFFSET for subsequent images Russell King
2016-06-17 19:44 ` [PATCH 2/2] arm: fix kernel image size Russell King
2016-06-21  7:43   ` Tony Lindgren
2016-06-21  9:47     ` Russell King - ARM Linux
2016-06-21 10:38       ` Tony Lindgren
2016-06-21 10:57         ` Tony Lindgren
2016-06-21 15:44           ` Russell King - ARM Linux
2016-06-21 16:55             ` Tony Lindgren
2016-06-21 21:51               ` Russell King - ARM Linux
2016-06-22  7:36                 ` Tony Lindgren [this message]
2016-06-22  8:29                   ` Russell King - ARM Linux
2016-06-22  8:51                     ` Tony Lindgren
2016-06-21 11:02   ` Mason
2016-06-21  6:11 ` [PATCH 0/2] Simple fix to the ARM kexec tools implementation Pratyush Anand
2016-06-21  8:20   ` Russell King - ARM Linux
2016-06-23  0:41     ` Simon Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160622073614.GZ22406@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).