On 2022/03/23 7:02, Tejun Heo wrote: > Hello, > > On Wed, Mar 23, 2022 at 09:00:07AM +1100, Dave Chinner wrote: >>> Yeah, you detected multiple issues at the same time. xfs sync is >>> participating in memory reclaim >> >> No it isn't. What makes you think it is part of memory reclaim? >> >> The xfs-sync workqueue exists solely to perform async flushes of >> dirty data at ENOSPC via sync_inodes_sb() because we can't call >> sync_inodes_sb directly in the context that hit ENOSPC due to locks >> and transaction contexts held. The paths that need this are >> buffered writes and file create (on disk inode allocation), neither >> of which are in the the memory reclaim path, either. >> >> So this work has nothing to do with memory reclaim, and as such it's >> not tagged with WQ_MEM_RECLAIM. > > Hmmm... yeah, I actually don't know the exact dependency here and the > dependency may not be real - e.g. the conclusion might be that loop is > conflating different uses and needs to split its use of workqueues into two > separate ones. Tetsuo, can you post more details on the warning that you're > seeing? > It was reported at https://lore.kernel.org/all/20210322060334.GD32426@xsang-OptiPlex-9020/ .
