On Wed, Aug 19, 2026 at 10:53:57PM +0800, Aristo Chen wrote: > Hi Tom, > > On Wed, Aug 19, 2026 at 6:10 AM Tom Rini <[email protected]> wrote: > > > > On Tue, Aug 18, 2026 at 01:23:14PM +0000, Aristo Chen wrote: > > > > > This is v2 of "bootm: size the noload decompression buffer from the > > > compressor header". Tom pushed back on v1 > > > (https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/) > > > on two grounds: > > > > > > 1. No concrete problem report driving the change. > > > 2. ~1297 platforms grew by ~170-400 bytes; the change is not > > > opt-in, so the size cost falls on everyone. > > > > So, the first example that pops up in my builds is imx8mn_beacon_2g. > > And for v1 of the series: > > aarch64: (for 1/1 boards) all +16384.0 data +14336.0 text +2048.0 > > imx8mn_beacon_2g: all +16384 data +14336 text +2048 > > u-boot: add: 0/0, grow: 1/0 bytes: 328/0 (328) > > function old new > > delta > > bootm_run_states 3316 3644 > > +328 > > > > And now for v2: > > aarch64: (for 1/1 boards) all +16384.0 data +14336.0 text +2048.0 > > imx8mn_beacon_2g: all +16384 data +14336 text +2048 > > u-boot: add: 0/0, grow: 1/0 bytes: 368/0 (368) > > function old new > > delta > > bootm_run_states 3316 3684 > > +368 > > > > Next, picking turris_mox as it enables ZSTD: > > v1: > > aarch64: (for 1/1 boards) all +472.0 text +472.0 > > turris_mox : all +472 text +472 > > u-boot: add: 2/0, grow: 1/0 bytes: 472/0 (472) > > function old new > > delta > > image_decomp_get_uncompressed_size - 416 > > +416 > > bootm_run_states 2360 2412 > > +52 > > zstd_get_frame_header - 4 > > +4 > > v2: > > aarch64: (for 1/1 boards) all +428.0 text +428.0 > > turris_mox : all +428 text +428 > > u-boot: add: 1/0, grow: 1/0 bytes: 428/0 (428) > > function old new > > delta > > bootm_run_states 2360 2784 > > +424 > > zstd_get_frame_header - 4 > > +4 > > > > So, that is better. Looking at smartweb, both iterations are the same: > > arm: (for 1/1 boards) all +96.0 text +96.0 > > smartweb : all +96 text +96 > > u-boot: add: 0/0, grow: 1/0 bytes: 76/0 (76) > > function old new > > delta > > bootm_run_states 3592 3668 > > +76 > > > > What's honestly concerning is chromebook_coral where v2 *shrinks*: > > u-boot: add: 0/0, grow: 0/-1 bytes: 0/-2 (-2) > > function old new > > delta > > bootm_load_os 520 518 > > -2 > > but v1 grows: > > u-boot: add: 1/0, grow: 1/0 bytes: 110/0 (110) > > function old new > > delta > > bootm_load_os 520 587 > > +67 > > image_decomp_get_uncompressed_size - 43 > > +43 > > > > That one is working as intended: chromebook_coral enables none of > GZIP/LZMA/LZ4/ZSTD, so it is one of the "bootm with no decompressor > at all" boards from the cover letter. In v2 every helper and its > switch case sit behind CONFIG_IS_ENABLED(<format>), so on that board > they all compile away and only the unchanged 8x fallback remains. > The -2 bytes is codegen noise from the restructure; I diffed the > disassembly and the function is otherwise unchanged. v1 grew there > because its helper in image.c was built unconditionally. Behaviour is > unchanged either way: with no decompressor enabled, a compressed > kernel_noload image already fails in image_decomp(). > > The imx8mn_beacon_2g result has a similar shape to what I measured > on am62x_evm_a53: both enable LTO, and on these LTO configurations > compiler inlining and layout make v2 a few tens of bytes larger > than v1 (+368 vs +328 here, with the growth landing inside > bootm_run_states either way). That is the trade of the per-format > split, which is what makes the no-decompressor boards free, trims > the gzip-only majority, and keeps each format individually > droppable. > > turris_mox is the non-LTO counterpart and shows the intended > direction for the multi-algorithm case: v2 comes in 44 bytes below > v1 there (+428 vs +472 in your run). > > smartweb is the expected gzip-only LTO case: both versions cost > essentially the same (+96 in your run). > > Thanks for the u-boot-size-test.sh pointer. I re-ran your four > boards with it against this series' base and reproduce your numbers > to within a few bytes of toolchain difference, including coral's -2 > (here: v1 +108 with bootm_load_os +65 plus the unconditional helper > +43, v2 -2). I will use the script for the size numbers from now on; > if you would like the cover letter regenerated with those numbers, I > am happy to respin as v3 with the code unchanged.
Thanks for explaining and digging a bit more. At the end of the day, I wish we could solve this problem, but have smaller growth, but I don't see it. So v2 is fine as-is from my point of view, no need to spin a v3 unless there's other feedback. -- Tom
signature.asc
Description: PGP signature
