[systemd-devel] udevd: increase maximum number of children

[Harald Hoyer]

On 28.11.2014 14:09, Harald Hoyer wrote:
> On 28.11.2014 13:59, Robert Milasan wrote:
>> On Fri, 28 Nov 2014 13:51:04 +0100
>> "Tom Gundersen" <teg at jklm.no> wrote:
>>  
>>>> Also the patch changes the logging level of 'maximum number of
>>>> children reached' to an error, this should be visible as an error
>>>> when the number has been reached.
>>>
>>> I don't think an error is appropriate here (as nothing actually
>>> fails). At most a warning I would say.
>>>
>>> Cheers,
>>>
>>> Tom
>>>
>>
>> This is an error, because the behavior makes the system not work
>> correctly.
>>
>> I don't care about a warning that much, but in this case and reference
>> bug, we see a bug and/or an error which is causes by the small amount of
>> children, or the impossibility of udev daemon to create new
>> children/workers, stopping the queue processing until the number of
>> children is lower the children_max.
>>
>> Anyway, please do as you wish as long as it gets fixed.
>>
> 
> 
> This is not true. It only defers the uevent until a worker is available. So
> logging it as an error is incorrect. It's a debug message.
> 
> We don't have unlimited resources. You don't do "make -j" with unlimited make
> jobs either for a kernel build to get the minimum build time.
> 
> Having 1024 concurrent blkid's running will slow down a machine significantly,
> because concurrent I/O over a single path is never good.
> 
> So, what we see is a lot of I/O errors because of timeouts on huge systems, if
> the bottleneck is saturated.
> 
> Ideally we would limit the concurrent I/O, but we can't know (in a simple way)
> where the bottleneck is. It might be a SAN behind FCoE, or iscsi and the
> network is the bottleneck.
> 
> That being said, I don't have a sane solution to satisfy everybody.
> 

Also interesting:

udev workers and the time to bring up 2000 LVM LVs on 2 disks.

https://plus.google.com/117537647502636167748/posts/eRJFhjLbpta