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
next prev parent 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).