[PATCH v2 1/2] lib: zstd: update to latest Linux zstd 1.5.2

[Tom Rini]

On Mon, Jan 02, 2023 at 04:02:06PM +0000, Maier, Brandon L                            Collins wrote:
> Hello Simon,
> 
> > -----Original Message-----
> > From: Simon Glass <sjg at chromium.org>
> > >
> > > > $ buildman -b zstd2 --boards dh_imx6,m53menlo,mvebu_espressobin-
> > 88f3720,sandbox,sandbox64,stm32mp15_dhcom_basic,stm32mp15_dhcor_basi
> > c,turris_mox,turris_omnia -sS
> > > > Summary of 3 commits for 9 boards (8 threads, 1 job per thread)
> > > > 01: Merge tag 'tpm-23122022' of
> > https://urldefense.com/v3/__https://source.denx.de/u-boot/custodians/u-
> > boot-tpm__;!!MvWE!SiCDjQxi4IOlpR2LYEviKe-
> > 1_MQirGfhHKYya94BvpeZgxBZ1YBd84kMf-FR0-VX0pY$
> > > >        arm:  w+   m53menlo dh_imx6
> > > > 02: lib: zstd: update to latest Linux zstd 1.5.2
> > > >    aarch64: (for 2/2 boards) all +535.5 rodata +965.5 text -430.0
> > > >        arm: (for 5/5 boards) all +4489.6 rodata +940.0 text +3549.6
> > 
> > That's a pretty stiff penalty. Do you know what has changed? Does it
> > support a lot more optional features? If so, could we make it optional
> > (even if default y)?
> > 
>  
> 
> I understand Linux replaced their custom zstd code with the Facebook zstd code, so the changes are widespread. The new zstd does support many optional performance features as documented in zstd's lib/README[1], which I have already added a KConfig to disable all of them in this patch. For reference, if I enable the performance options the build size increases as so:
> 
> aarch64: (for 2/2 boards) all +27432.0 rodata +320.0 text +27112.0
>        arm: (for 5/5 boards) all +21801.6 rodata +256.0 text +21545.6
>    sandbox: (for 2/2 boards) all +59004.0 bss +16.0 rodata +800.0 text +58188.0
> 
> I haven't had any luck finding another way to decrease build size.
> 
> [1] https://github.com/facebook/zstd/blob/dev/lib/README.md#modular-build

After skimming over that, did you see if not disabling inlining, and
letting the compiler figure it out is a big size penalty?  Also, while
the arch-level details are good, a specific platform set of numbers
instead might give some ideas on where maybe reductions could come from.
Finally, what is the whole list of platforms that grow? It's all not
ideal, yes, but it looks like BTRFS is the main user, right now, which
isn't widely enabled. So maybe we can look towards improving upstream a
bit here, if motivated.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230102/e9b15f15/attachment.sig>