Re: [PATCH] loop: add WQ_MEM_RECLAIM flag to per device workqueue

[Tejun Heo <tj@kernel.org>]

On Tue, Mar 22, 2022 at 08:17:43AM +0900, Tetsuo Handa wrote:
> On 2022/03/22 8:04, Tejun Heo wrote:
> > But why are you dropping the flag from their intended users?
> 
> As far as I can see, the only difference __WQ_LEGACY makes is whether
> "workqueue: WQ_MEM_RECLAIM %s:%ps is flushing !WQ_MEM_RECLAIM %s:%ps"
> warning is printed or not. What are the intended users?

The old create_workqueue() and friends always imply WQ_MEM_RECLAIM because
they all used to be served dedicated kthreads. The growing number of
kthreads used this way became a headache. There were too many of these
kthreads sitting around doing nothing. In some niche configurations, they
ate up enough PIDs to cause boot failrues.

To address the issue, the new implementation made the workqueues share pools
of workers. However, this means that forward progress can't be guaranteed
under memory pressure, so workqueues which are depended upon during memory
reclaim now need to set WQ_MEM_RECLAIM explicitly to request a dedicated
rescuer thread.

The legacy flushing warning is telling us that those workqueues can be
converted to alloc_workqueue + WQ_MEM_RECLAIM as we know them to be
participating in memory reclaim (as they're flushing one of the explicitly
marked workqueues). So, if you spot them, the right thing to do is
converting all the involved workqueues to use alloc_workqueue() +
WQ_MEM_RECLAIM.

Thanks.

-- 
tejun