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

[Tejun Heo <tj@kernel.org>]

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