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 <bkhomuts@xxxxxxxxxx> 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 <lruzicka@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
--Lukáš Růžička
FEDORA QE, RHCE
Purkyňova 115
612 45 Brno - Královo Pole
![]()
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
--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
Release configuration management engineer, PnT DevOps
Red Hat Czech s.r.o
T: +420532270289 IRC: bkhomuts
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
