All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
	linux-arm-kernel@lists.infradead.org,
	"Russell King" <linux@armlinux.org.uk>,
	"Nick Terrell" <terrelln@fb.com>,
	"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@vger.kernel.org
Subject: Re: [PATCH 0/3] ARM ZSTD boot compression
Date: Sat, 15 Apr 2023 00:50:01 +0200	[thread overview]
Message-ID: <ZDnYme3w3T6310MJ@probook> (raw)
In-Reply-To: <9ae523ae-aad4-40b1-8b6b-d5e18bf8b92a@app.fastmail.com>


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

On Wed, Apr 12, 2023 at 11:33:15PM +0200, 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
> 
> That seems unexpected, as the usual numbers say it's about 25%
> slower than LZO. Do you have an idea why it is so much slower
> here?

No clear idea.

I guess it might be related to caching or unaligned memory accesses
somehow.

I suspected CONFIG_CPU_DCACHE_WRITETHROUGH, which was enabled, but
disabling it didn't improve performance.

> How long does it take to decompress the generated arch/arm/boot/Image
> file in user space on the same hardware using lzop and zstd?


Unfortunately, the unzstd userspace tool requires a buffer of of 128 MiB
(the window size), which is too big for my usual devboard (which has about
100 MiB available). I'd have to test on a different board.


Jonathan

---
# uname -a
Linux buildroot 6.3.0-rc6-00020-g023058d50f2f #1212 PREEMPT Fri Apr 14 20:58:21 CEST 2023 armv5tejl GNU/Linux

# ls -lh
total 13M
-rw-r--r--    1 root     root        7.5M Jan  1 00:07 piggy.lzo
-rw-r--r--    1 root     root        5.8M Jan  1 00:07 piggy.zstd

# time lzop -d piggy.lzo -c > /dev/null
lzop: piggy.lzo: warning: ignoring trailing garbage in lzop file
Command exited with non-zero status 2
real    0m 3.38s
user    0m 3.20s
sys     0m 0.18s

# time unzstd piggy.zstd -c > /dev/null
[  858.270000] __vm_enough_memory: pid: 114, comm: unzstd, not enough memory for the allocation
piggy.zstd : Decoding error (36) : Allocation error : not enough memory
Command exited with non-zero status 1
real    0m 0.03s
user    0m 0.01s
sys     0m 0.03s

[-- 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: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
	linux-arm-kernel@lists.infradead.org,
	"Russell King" <linux@armlinux.org.uk>,
	"Nick Terrell" <terrelln@fb.com>,
	"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@vger.kernel.org
Subject: Re: [PATCH 0/3] ARM ZSTD boot compression
Date: Sat, 15 Apr 2023 00:50:01 +0200	[thread overview]
Message-ID: <ZDnYme3w3T6310MJ@probook> (raw)
In-Reply-To: <9ae523ae-aad4-40b1-8b6b-d5e18bf8b92a@app.fastmail.com>

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

On Wed, Apr 12, 2023 at 11:33:15PM +0200, 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
> 
> That seems unexpected, as the usual numbers say it's about 25%
> slower than LZO. Do you have an idea why it is so much slower
> here?

No clear idea.

I guess it might be related to caching or unaligned memory accesses
somehow.

I suspected CONFIG_CPU_DCACHE_WRITETHROUGH, which was enabled, but
disabling it didn't improve performance.

> How long does it take to decompress the generated arch/arm/boot/Image
> file in user space on the same hardware using lzop and zstd?


Unfortunately, the unzstd userspace tool requires a buffer of of 128 MiB
(the window size), which is too big for my usual devboard (which has about
100 MiB available). I'd have to test on a different board.


Jonathan

---
# uname -a
Linux buildroot 6.3.0-rc6-00020-g023058d50f2f #1212 PREEMPT Fri Apr 14 20:58:21 CEST 2023 armv5tejl GNU/Linux

# ls -lh
total 13M
-rw-r--r--    1 root     root        7.5M Jan  1 00:07 piggy.lzo
-rw-r--r--    1 root     root        5.8M Jan  1 00:07 piggy.zstd

# time lzop -d piggy.lzo -c > /dev/null
lzop: piggy.lzo: warning: ignoring trailing garbage in lzop file
Command exited with non-zero status 2
real    0m 3.38s
user    0m 3.20s
sys     0m 0.18s

# time unzstd piggy.zstd -c > /dev/null
[  858.270000] __vm_enough_memory: pid: 114, comm: unzstd, not enough memory for the allocation
piggy.zstd : Decoding error (36) : Allocation error : not enough memory
Command exited with non-zero status 1
real    0m 0.03s
user    0m 0.01s
sys     0m 0.03s

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

  parent reply	other threads:[~2023-04-14 22:51 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
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 [this message]
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=ZDnYme3w3T6310MJ@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@fb.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.