Unfortunately, the only machine I have access to with an HDD as the system drive is running Ubuntu 20.04 LTS, which doesn’t have a multi-threaded version of fixfiles. So I can’t test this on an HDD-only system.

Still, here are the timings on a 4-core Atom machine with a SATA SSD and a large SATA HDD data drive mounted at /srv:

$ sudo bash -c 'sync; for i in $(seq 1 3); do echo $i > /proc/sys/vm/drop_caches; done; time fixfiles -T 1 restore'

[…]

real    6m39.521s
user    5m6.599s
sys    0m42.000s

$ sudo bash -c 'sync; for i in $(seq 1 3); do echo $i > /proc/sys/vm/drop_caches; done; time fixfiles -T 0 restore'

[…]

real    3m16.602s
user    5m25.444s
sys    0m50.843s

I took care to drop various kernel caches, especially including dentry and inode caches, to make this more reproducible.

Here are the timings on a very modern 16-core machine with NVMe SSD storage:

$ sudo bash -c 'sync; for i in $(seq 1 3); do echo $i > /proc/sys/vm/drop_caches; done; time fixfiles -T 1 restore'

[…]

real    3m17.277s
user    2m42.447s
sys    0m24.403s

$ sudo bash -c 'sync; for i in $(seq 1 3); do echo $i > /proc/sys/vm/drop_caches; done; time fixfiles -T 0 restore'

[…]

real    0m58.154s
user    4m27.209s
sys    0m58.127s
On 7/18/22 11:48, Gary Buhrmaster wrote:
On Mon, Jul 18, 2022 at 6:44 AM Petr Lautrbach <plautrba@redhat.com> wrote:
Dan Čermák <dan.cermak@cgc-instruments.de> writes:
Just out of curiosity, how large is the speedup typically?


      
It depends on the number of threads your machine has. But you could get some
data for comparison using `fixfiles -T 1 restore` and `fixfiles -T 0
restore` on a running system. The following times are reported on my workstation:

Has anyone run such a test on a system using
classic ("spinning rust") HDDs?  It is sometimes
the case that parallelizing activities that are I/O
intensive can result in excessive seek activity
that can result in rather elongated elapsed times
(much worse than single threaded operation).
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure