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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022/03/23 7:59, Dave Chinner wrote:
> I don't know what the solution is, but if the fix is "xfs needs to
> mark a workqueue that has nothing to do with memory reclaim as
> WQ_MEM_RECLAIM because of the loop device" then we're talking about
> playing workqueue whack-a-mole across the entire kernel forever
> more....

During an attempt to fix lockdep warning caused by calling destroy_workqueue()
when loop device's autoclear operation is triggered with disk->open_mutex held,
Christoph has proposed a patch which avoids calling destroy_workqueue() by using
a global WQ. But like demonstrated at
https://lkml.kernel.org/r/22b51922-30c6-e4ed-ace9-5620f877682c@xxxxxxxxxxxxxxxxxxx ,
I confirmed that the loop module needs to reserve one "struct task_struct" on each
loop device's WQ. And creating per loop device WQ with WQ_MEM_RECLAIM flag is the
only available method for reserving "struct task_struct" on each loop device's WQ.
That is, WQ_MEM_RECLAIM flag is required for not only surviving memory pressure
situation but also surviving max active limitation.

But like demonstrated at
https://lkml.kernel.org/r/61f41e56-3650-f0fc-9ef5-7e19fe84e6b7@xxxxxxxxxxxxxxxxxxx ,
creating per loop device WQ with WQ_MEM_RECLAIM flag without __WQ_LEGACY flag will hit
this "workqueue: WQ_MEM_RECLAIM %s:%ps is flushing !WQ_MEM_RECLAIM %s:%ps" warning.

And if WQs used by filesystem side do not want to use WQ_MEM_RECLAIM flag, the loop
module would have to abuse __WQ_LEGACY flag in order to suppress this warning.



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux