Messages in this thread | | | Date | Mon, 4 Apr 2022 22:59:23 +0200 | Subject | Re: Possible performance regression with CONFIG_SQUASHFS_DECOMP_SINGLE | From | Ahmad Fatoum <> |
| |
Hello Phillip,
On 16.03.22 06:34, Phillip Lougher wrote: > Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > >> Hello, >> >> This an issue we had with v5.15 that we have since successfully worked around. >> I am reporting it here as a pointer in case someone else runs into this and as >> a heads up that there seems to be an underlying performance regression, so >> here it goes: >> > > [snip] > >> >> Looking through the original kernel configuration we found that it has >> CONFIG_SQUASHFS_DECOMP_SINGLE=y and CONFIG_SQUASHFS_FILE_CACHE=y. >> >> Once changed to CONFIG_SQUASHFS_FILE_DIRECT=y and >> CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y, we were below 40s as we want. > > This sounds like the slow-down that was introduced by commit c1f6925e1091 > "mm: put readahead pages in cache earlier" (Linux V5.8) > > This commit prevents Squashfs from doing it's own readahead, which > causes a slow-down in performance. The slow-down is noticable when > using a single decompressor (CONFIG_SQUASHFS_DECOMP_SINGLE=y), and > can be solved by moving to a multi-decompressor configuration, because > it removes contention on a single buffer in the single decompressor case. > > This has been already been fixed by commit 9eec1d897139 > "squashfs: provide backing_dev_info in order to disable read-ahead" > which is in Linux 5.17-rc1.
I just updated to v5.17.1 and I can confirm that this commit fixes the performance regression. Single decompressor case is now nearly as fast as multi decompressor. Reverting the fix increased boot time from 30s~ to 2min30s.
Thanks for clearing this up!
Cheers, Ahmad
> > Phillip >
-- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
| |