On 30/04/2024 15:44, Joel Colledge wrote: > On Tue, 30 Apr 2024 at 16:28, Christian Loehle <christian.loehle@xxxxxxx> wrote: >> Is this an issue for delay > 0 too somehow? > > I believe it is. If there is simply no IO to the delay device, then > nothing will wake the new thread and the same issue will occur. Yes, but might be better to just set_current_state(TASK_INTERRUPTIBLE); instead of the wakeup. > > I haven't yet reproduced this case, because the system I am testing on > submits reads on any new block device and I don't know offhand how to > disable them. I think the reads are from scans for multipathd, > bcachefs or similar. > >> Indeed if we don't have a delay the process will never be woken up, >> but in that case, why create the worker in the first place? > > I agree. If this were only an issue with delay == 0, it would make > more sense not to create the worker at all. > > As mentioned above, I believe the issue can occur with delay > 0. So > not creating the worker in the delay == 0 case is an additional > optimization and out of the scope of this change. Ah right because of the delay_is_fast() definition that is slightly more work. Regards, Christian.
