On Fri, Sep 27, 2024 at 07:25:16PM GMT, Hillf Danton <hdanton@xxxxxxxx> wrote:
> > Or if the negation is correct, why do you mean that processed work item
> > is _not_ preventing thread T from running (in the case I left quoted
> > above)?
> >
> If N (N > 1) cgroup work items are queued before one cpu hotplug work, then
> 1) workqueue worker1 dequeues cgroup work1 and executes it,
> 2) worker1 goes off cpu and falls in nap because of failure of acquiring
> cgroup_mutex,
> 3) worker2 starts processing cgroup work2 and repeats 1) and 2),
> 4) after N sleepers, workerN+1 dequeus the hotplug work and executes it
> and completes finally.
My picture of putting everything under one system_wq worker was a bit
clumsy. I see how other workers can help out with processing the queue,
that's where then N >= WQ_DFL_ACTIVE comes into play, then this gets
stuck(?). [1]
IOW, if N < WQ_DFL_ACTIVE, the mutex waiters in the queue are harmless.
> Clear lad?
I hope, thanks!
Michal
[1] I don't see a trivial way how to modify lockdep to catch this
(besides taking wq saturation into account it would also need to
propagate some info across complete->wait_for_completion).
Attachment:
signature.asc
Description: PGP signature
