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
