Re: [OS-BUILD PATCHv5] redhat/kernel.spec.template: Parallelize compression

2023-01-23 Thread Denys Vlasenko (via Email Bridge)
From: Denys Vlasenko on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2254#note_1249493515

We usually have 2000..4000 modules.
With e.g. -n 1000, you obviously risk having fewer "xz" processes than CPUs.
Even with -n 100, conceivably on a big machine, you can underutilize CPUs.
OTOH, -n 1, you can spend more time starting a new xz process than compressing
a module, if it's a small module.
So yes, -n16 is an arbitrary choice, but there is logic why it should be
somewhere in [10,100] range.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: [OS-BUILD PATCHv5] redhat/kernel.spec.template: Parallelize compression

2023-01-23 Thread Herton R. Krzesinski (via Email Bridge)
From: Herton R. Krzesinski on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2254#note_1249483495

I don't think we need to overengineer this. I agree fork costs can be
something to avoid, but we don't need a separate script. If there is a
heuristic for it we should calculate it and and give to ```-n``` option. But
I'm ok the way it is right now. If you want to determine an heuristic and
measure the difference feel free to.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: [OS-BUILD PATCHv5] redhat/kernel.spec.template: Parallelize compression

2023-01-23 Thread Prarit Bhargava (via Email Bridge)
From: Prarit Bhargava on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2254#note_1249133186

I'd argue then the original version (with a separate parallel script) would be
preferable than a magic number.  @hertonrk-rh, your thoughts?
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: [OS-BUILD PATCHv5] redhat/kernel.spec.template: Parallelize compression

2023-01-23 Thread Denys Vlasenko (via Email Bridge)
From: Denys Vlasenko on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2254#note_1249068590

"-n 1" will spawn one "xz" per every module. This incurs some startup costs
(fork+exec+library loading).
How about "-n 16", so that each xz process compresses 16 modules, decreasing
startup costs by more than 90%? rhel7 and rhel8 already use this approach.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue