Franck Bui
88bd5a32e8
Follow-up forfaae64fa3d, which increased the default number of udev workers per cpu regardless of how big the system is. It's not really clear from the commit message if the new number of workers improved the overall time for the boot process or only reduced the number of times the max number of children limit was reached (and in this case5406c36844commit might have been more appropriate in the first place). But systems with ~1000 CPUs are not rare these days and the worker numbers get quite large with CPU factor of 8. Spawning more than 2000 workers can't be healthy on any system, no matter how big. Indeed the main mistake is the belief that udev is CPU-intensive, and thus the number of allowed workers has to increase with the number of CPUs. It is not, at probably has never been. It's I/O bound, and sometimes, bound by resources such as locks. This is an argument to: - scale only weakly with the number of CPUs, and the rationale to switch back to a scale factor C=2 but with a higher offset number which should affect systems with a small number of CPUs only. With this patch applied the offset is increased from O=8 to O=16. - put an absolute maximum limit to make sure no more than 2048 workers are spawned no matter how big the system is. This still provides more workers for the laptop cases (where the number of CPUs is limited), while avoiding sky-rocketing numbers for big systems. Note that on most desktop systems, the memory limit will kick in. The following table collects numbers about children-max. For each scenario, the first column is the "cpu_limit" limit, and the second number is the minimum amount of memory for the "cpu_limit" limit to become relevant (with less RAM, memory will limit the number of children thus "mem_limit" will become the active limit). | > v240 | < v240 | this patch | CPUs | C = 8, O = 8 | C = 2, O = 8 | C = 2, O = 16 | ------------------------------------------------------- 1 | 16 2 | 10 1.3 | 18 2 | 2 | 24 3 | 12 1.5 | 20 2 | 4 | 40 5 | 16 2 | 24 3 | 8 | 72 9 | 24 3 | 32 4 | 16 | 136 17 | 40 5 | 48 5 | 64 | 520 65 | 136 17 | 144 18 | 1024 | 8200 1025 | 2056 263 | 2048 256 | 2048 |16392 2049 | 4104 513 | 2048 256 | This patch is mainly based on Martin Wilck's analyze and comments.
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.