Hello, I posted more benchmark results in this article: https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS
In short, bigger block size and higher compression ratio does not increase the installation time for Fedora Workstation. I saw the opposite effect. The Zstd compression performed worse than XZ in the compression test. On the other hand, 40% lower installation time for Zstd, was documented. Along with the CPU consumption 37% lower. All installation tests were performed from and to local NVMe storage. Which I consider far from real life scenario. I plan to perform more testing, with slower installation media, and will post the results next weekend. I did not evaluate CONFIG_SQUASHFS_DECOMP_MULTI this weekend. On Sat, Jan 11, 2020 at 4:38 PM Bohdan Khomutskyi <bkhom...@redhat.com> wrote: > Thanks everyone for your comments. These are all valid concerns. > > I filed a new change proposal at > https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS. > > I'll run more benchmarks, including using Zstd compression algorithm, and > will post results. > Hopefully this weekend, I'll also try to measure the impact of the > compression, block size versus installation time. > > Also, the decompression of SquashFS is currently happening in single > thread. This could be changed with CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU > kernel build-time configuration option. I'll file a new change proposal for > it, along with benchmarks. > > On Thu, Jan 9, 2020 at 11:13 AM Lukas Ruzicka <lruzi...@redhat.com> wrote: > >> >> >>> Why stacked images? Consider a single base.img that's maybe 1G, and >>> now you don't have to do separate composes for server, cloud, GNOME, >>> KDE, Cinnamon, LXQt, Astronomy that repeat a lot of the same steps, >>> including expensive steps like compressing the same things over and >>> over again. Just do a 'dnf group install' tacked onto that base.img, >>> the work being done is custom for that output, rather than repetitive. >>> Not complicated. It would be fast enough that the high level variants >>> could be composed on demand. Seconds. It'd be fast enough to queue it >>> for download within the hour. >>> >> >> Well, I would like that. >> +1 >> >> >> >>> >>> >>> -- >>> Chris Murphy >>> _______________________________________________ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >>> >> >> >> -- >> >> Lukáš Růžička >> >> FEDORA QE, RHCE >> >> Red Hat >> >> <https://www.redhat.com> >> >> Purkyňova 115 >> >> 612 45 Brno - Královo Pole >> >> lruzi...@redhat.com >> TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted> >> _______________________________________________ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > > > -- > Bohdan Khomutskyi, RHCE > Release configuration management engineer, PnT DevOps > Red Hat Czech s.r.o > T: +420532270289 IRC: bkhomuts > -- Bohdan Khomutskyi, RHCE Release configuration management engineer, PnT DevOps Red Hat Czech s.r.o T: +420532270289 IRC: bkhomuts
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
