On 2022/03/22 8:27, Tejun Heo wrote:
> 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.
OK.
>
> 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.
OK.
>
> The legacy flushing warning is telling us that those workqueues can be
s/can be/must 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.
Then, can the description of
__WQ_LEGACY = 1 << 18, /* internal: create*_workqueue() */
be improved to something like
/*
* This flag disables deadlock detection which can happen when flushing
* a work item in !WQ_MEM_RECLAIM workqueue from WQ_MEM_RECLAIM workqueue.
* But try to avoid using this flag, by adding WQ_MEM_RECLAIM to all WQs which
* can be involved where a guarantee of forward progress under memory pressure
* is required.
*/
? Current /* internal: create*_workqueue() */ tells me nothing.
My question is: I want to add WQ_MEM_RECLAIM flag to the WQ used by loop module
because this WQ is involved upon writeback operation. But unless I add both
__WQ_LEGACY | WQ_MEM_RECLAIM flags to the WQ used by loop module, we will hit
WARN_ONCE(worker && ((worker->current_pwq->wq->flags &
(WQ_MEM_RECLAIM | __WQ_LEGACY)) == WQ_MEM_RECLAIM),
warning because e.g. xfs-sync WQ used by xfs module is not using WQ_MEM_RECLAIM flag.
mp->m_sync_workqueue = alloc_workqueue("xfs-sync/%s",
XFS_WQFLAGS(WQ_FREEZABLE), 0, mp->m_super->s_id);
You are suggesting that the correct approach is to add WQ_MEM_RECLAIM flag to WQs
used by filesystems when adding WQ_MEM_RECLAIM flag to the WQ used by loop module
introduces possibility of hitting
WARN_ONCE(worker && ((worker->current_pwq->wq->flags &
(WQ_MEM_RECLAIM | __WQ_LEGACY)) == WQ_MEM_RECLAIM),
warning (instead of either adding __WQ_LEGACY | WQ_MEM_RECLAIM flags to the WQ used
by loop module or giving up WQ_MEM_RECLAIM flag for the WQ used by loop module),
correct?
