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(a)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 <lruzicka(a)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(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)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
>
> lruzicka(a)redhat.com
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <
https://redhat.com/trusted>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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