Hello, On Wed, Mar 23, 2022 at 09:59:14AM +1100, Dave Chinner wrote: > The filesystem buffered write IO path isn't part of memory reclaim - > it's a user IO path and I think most filesystems will treat it that > way. We can argue the semantics but anything in fs / io path which sit on write path should be marked MEM_RECLAIM because they can be depended upon while cleaning dirty pages. This isn't a layering problem or anything. It's just what that flag is for. > If the loop device IO mechanism means that every ->write_iter path > needs to be considered as directly in the memory reclaim path, then > that means a huge amount of the kernel needs to be considered as "in > memory reclaim". i.e. it's not just this one XFS workqueue that is > going have this problem - it's any workqueue that can be waited on > by the incoming IO path. > > For example, network filesystem might put the network stack directly > in the IO path. Which means if we then put loop on top of that > filesystems, various workqueues in the network stack may now need to > be considered as running under the memory reclaim path because of > the loop block device. > > 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.... Yeah, all those workqueues must be and most of them are already tagged with MEM_RECLAIM. The network drivers are kinda painful and we *can* make them conditional (on it sitting in the io path) if that ever becomes necessary but the number hasn't been problematic till now. Thanks. -- tejun
