On Mo, 2021-06-07 at 23:30 +0800, heming.zhao@xxxxxxxx wrote: > On 6/7/21 6:27 PM, Martin Wilck wrote: > > On So, 2021-06-06 at 11:35 -0500, Roger Heflin wrote: > > > This might be a simpler way to control the number of threads at > > > the > > > same time. > > > > > > On large machines (cpu wise, memory wise and disk wise). I have > > > only seen lvm timeout when udev_children is set to default. The > > > default seems to be set wrong, and the default seemed to be tuned > > > for > > > a case where a large number of the disks on the machine were > > > going to > > > be timing out (or otherwise really really slow), so to support > > > this > > > case a huge number of threads was required.. I found that with > > > it > > > set to default on a close to 100 core machine that udev got about > > > 87 > > > minutes of time during the boot up (about 2 minutes). Changing > > > the > > > number of children to =4 resulted in udev getting around 2-3 > > > minutes > > > in the same window, and actually resulted in a much faster boot > > > up > > > and a much more reliable boot up (no timeouts). > > > > Wow, setting the number of children to 4 is pretty radical. We > > decrease > > this parameter often on large machines, but we never went all the > > way > > down to a single-digit number. If that's really necessary under > > whatever circumstances, it's clear evidence of udev's deficiencies. > > > > I am not sure if it's better than Heming's suggestion though. It > > would > > affect every device in the system. It wouldn't even be possible to > > process more than 4 totally different events at the same time. > > > > hello > > I tested udev.children_max with value 1, 2 & 4. The results showed it > didn't take effect, and the booting time even longer than before. > This solution may suite for some special cases. Thanks, good to know. There may be other scenarios where Roger's suggestion might help. But it should be clear that no distribution will ever use such low limits, because it'd slow down booting on other systems unnecessarily. Thanks, Martin _______________________________________________ linux-lvm mailing list linux-lvm@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
