All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Neuschäfer" <j.neuschaefer@gmx.net>
To: Nick Terrell <terrelln@meta.com>
Cc: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Russell King" <linux@armlinux.org.uk>,
	"Tony Lindgren" <tony@atomide.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Sebastian Reichel" <sebastian.reichel@collabora.com>,
	"Hawkins, Nick" <nick.hawkins@hpe.com>,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"Xin Li" <xin3.li@intel.com>,
	"Seung-Woo Kim" <sw0312.kim@samsung.com>,
	"Paul Bolle" <pebolle@tiscali.nl>,
	"Bart Van Assche" <bvanassche@acm.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] ARM ZSTD boot compression
Date: Fri, 13 Oct 2023 03:27:12 +0200	[thread overview]
Message-ID: <ZSic8JsHGIlfuwhp@probook> (raw)
In-Reply-To: <1C6CE84E-557D-4436-BF13-E7275DE390A8@meta.com>


[-- Attachment #1.1: Type: text/plain, Size: 1952 bytes --]

On Thu, Oct 12, 2023 at 10:33:23PM +0000, Nick Terrell wrote:
> > On Apr 14, 2023, at 10:00 PM, Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote:
> > On Thu, Apr 13, 2023 at 01:13:21PM +0200, Arnd Bergmann wrote:
> >> On Wed, Apr 12, 2023, at 23:33, Arnd Bergmann wrote:
> >>> On Wed, Apr 12, 2023, at 23:21, Jonathan Neuschäfer wrote:
> >>>> This patchset enables ZSTD kernel (de)compression on 32-bit ARM.
> >>>> Unfortunately, it is much slower than I hoped (tested on ARM926EJ-S):
> >>>> 
> >>>> - LZO:  7.2 MiB,  6 seconds
> >>>> - ZSTD: 5.6 MiB, 60 seconds
[...]
> > For ZSTD as used in kernel decompression (the zstd22 configuration), the
> > window is even bigger, 128 MiB. (AFAIU)
> 
> Sorry, I’m a bit late to the party, I wasn’t getting LKML email for some time...
> 
> But this is totally configurable. You can switch compression configurations
> at any time. If you believe that the window size is the issue causing speed
> regressions, you could use a zstd compression to use a e.g. 256KB window
> size like this:
> 
>   zstd -19 --zstd=wlog=18
> 
> This will keep the same algorithm search strength, but limit the decoder memory
> usage.

Noted.

> I will also try to get this patchset working on my machine, and try to debug.
> The 10x slower speed difference is not expected, and we see much better speed
> in userspace ARM. I suspect it has something to do with the preboot environment.
> E.g. when implementing x86-64 zstd kernel decompression, I noticed that
> memcpy(dst, src, 16) wasn’t getting inlined properly, causing a massive performance
> penalty.

In the meantime I've seen 8s for ZSTD vs. 2s for other algorithms, on
only mildly less ancient hardware (Hi3518A, another ARM9 SoC), so I
think the main culprit here was particularly bad luck in my choice of
test hardware.

The inlining issues are a good point, noted for the next time I work on this.


Thanks,
Jonathan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: "J. Neuschäfer" <j.neuschaefer@gmx.net>
To: Nick Terrell <terrelln@meta.com>
Cc: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Russell King" <linux@armlinux.org.uk>,
	"Tony Lindgren" <tony@atomide.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Sebastian Reichel" <sebastian.reichel@collabora.com>,
	"Hawkins, Nick" <nick.hawkins@hpe.com>,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"Xin Li" <xin3.li@intel.com>,
	"Seung-Woo Kim" <sw0312.kim@samsung.com>,
	"Paul Bolle" <pebolle@tiscali.nl>,
	"Bart Van Assche" <bvanassche@acm.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] ARM ZSTD boot compression
Date: Fri, 13 Oct 2023 03:27:12 +0200	[thread overview]
Message-ID: <ZSic8JsHGIlfuwhp@probook> (raw)
In-Reply-To: <1C6CE84E-557D-4436-BF13-E7275DE390A8@meta.com>

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

On Thu, Oct 12, 2023 at 10:33:23PM +0000, Nick Terrell wrote:
> > On Apr 14, 2023, at 10:00 PM, Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote:
> > On Thu, Apr 13, 2023 at 01:13:21PM +0200, Arnd Bergmann wrote:
> >> On Wed, Apr 12, 2023, at 23:33, Arnd Bergmann wrote:
> >>> On Wed, Apr 12, 2023, at 23:21, Jonathan Neuschäfer wrote:
> >>>> This patchset enables ZSTD kernel (de)compression on 32-bit ARM.
> >>>> Unfortunately, it is much slower than I hoped (tested on ARM926EJ-S):
> >>>> 
> >>>> - LZO:  7.2 MiB,  6 seconds
> >>>> - ZSTD: 5.6 MiB, 60 seconds
[...]
> > For ZSTD as used in kernel decompression (the zstd22 configuration), the
> > window is even bigger, 128 MiB. (AFAIU)
> 
> Sorry, I’m a bit late to the party, I wasn’t getting LKML email for some time...
> 
> But this is totally configurable. You can switch compression configurations
> at any time. If you believe that the window size is the issue causing speed
> regressions, you could use a zstd compression to use a e.g. 256KB window
> size like this:
> 
>   zstd -19 --zstd=wlog=18
> 
> This will keep the same algorithm search strength, but limit the decoder memory
> usage.

Noted.

> I will also try to get this patchset working on my machine, and try to debug.
> The 10x slower speed difference is not expected, and we see much better speed
> in userspace ARM. I suspect it has something to do with the preboot environment.
> E.g. when implementing x86-64 zstd kernel decompression, I noticed that
> memcpy(dst, src, 16) wasn’t getting inlined properly, causing a massive performance
> penalty.

In the meantime I've seen 8s for ZSTD vs. 2s for other algorithms, on
only mildly less ancient hardware (Hi3518A, another ARM9 SoC), so I
think the main culprit here was particularly bad luck in my choice of
test hardware.

The inlining issues are a good point, noted for the next time I work on this.


Thanks,
Jonathan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-10-13  1:29 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-12 21:21 [PATCH 0/3] ARM ZSTD boot compression Jonathan Neuschäfer
2023-04-12 21:21 ` Jonathan Neuschäfer
2023-04-12 21:21 ` [PATCH 1/3] ARM: compressed: Pass the actual output length to the decompressor Jonathan Neuschäfer
2023-04-12 21:21   ` Jonathan Neuschäfer
2023-04-12 21:42   ` Linus Walleij
2023-04-12 21:42     ` Linus Walleij
2023-04-12 21:48   ` Florian Fainelli
2023-04-12 21:48     ` Florian Fainelli
2023-04-13  5:20   ` Tony Lindgren
2023-04-13  5:20     ` Tony Lindgren
2023-04-15  1:52     ` Jonathan Neuschäfer
2023-04-15  1:52       ` Jonathan Neuschäfer
2023-04-12 21:21 ` [PATCH 2/3] ARM: compressed: Bump MALLOC_SIZE to 128 KiB Jonathan Neuschäfer
2023-04-12 21:21   ` Jonathan Neuschäfer
2023-04-12 21:43   ` Linus Walleij
2023-04-12 21:43     ` Linus Walleij
2023-04-12 21:48   ` Florian Fainelli
2023-04-12 21:48     ` Florian Fainelli
2023-05-02  8:39   ` Russell King (Oracle)
2023-05-02  8:39     ` Russell King (Oracle)
2023-04-12 21:21 ` [PATCH 3/3] ARM: compressed: Enable ZSTD compression Jonathan Neuschäfer
2023-04-12 21:21   ` Jonathan Neuschäfer
2023-04-12 21:45   ` Linus Walleij
2023-04-12 21:45     ` Linus Walleij
2023-04-12 21:49   ` Florian Fainelli
2023-04-12 21:49     ` Florian Fainelli
2023-04-12 21:33 ` [PATCH 0/3] ARM ZSTD boot compression Arnd Bergmann
2023-04-12 21:33   ` Arnd Bergmann
2023-04-13 11:13   ` Arnd Bergmann
2023-04-13 11:13     ` Arnd Bergmann
2023-04-15  2:00     ` Jonathan Neuschäfer
2023-04-15  2:00       ` Jonathan Neuschäfer
2023-10-12 22:33       ` Nick Terrell
2023-10-12 22:33         ` Nick Terrell
2023-10-13  1:27         ` J. Neuschäfer [this message]
2023-10-13  1:27           ` J. Neuschäfer
2023-10-20 18:53           ` Nick Terrell
2023-10-20 18:53             ` Nick Terrell
2023-04-14 22:50   ` Jonathan Neuschäfer
2023-04-14 22:50     ` Jonathan Neuschäfer

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=ZSic8JsHGIlfuwhp@probook \
    --to=j.neuschaefer@gmx.net \
    --cc=arnd@arndb.de \
    --cc=bvanassche@acm.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=f.fainelli@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=ndesaulniers@google.com \
    --cc=nick.hawkins@hpe.com \
    --cc=pebolle@tiscali.nl \
    --cc=sebastian.reichel@collabora.com \
    --cc=sw0312.kim@samsung.com \
    --cc=terrelln@meta.com \
    --cc=tony@atomide.com \
    --cc=xin3.li@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.