Re: How to favor memory allocations for WQ_MEM_RECLAIM threads?

[Tejun Heo <tj@kernel.org>]

Hello,

On Wed, Mar 08, 2017 at 08:21:32AM +1100, Dave Chinner wrote:
> > I don't see how whether something is running off of a rescuer or not
> > matters here.  The only thing workqueue guarantees is that there's
> > gonna be at least one kworker thread executing work items from the
> > workqueue.  Running on a rescuer doesn't necessarily indicate memory
> > pressure condition.
> 
> That's news to me. In what situations do we run the rescuer thread
> other than memory allocation failure when queuing work?

It's a timeout based mechanism.  Whevever the delay might be coming
from, the rescuer kicks in if the workqueue fails to make forward
progress for a while.  The only thing which can induce delay there is
kthread creation path, which usually gets blocked on memory pressure
but it could easily be something else - severe cpu contention,
somebody holding some mutex for too long, whatever.

> > It's implementable for sure.  I'm just not sure how it'd help
> > anything.  It's not a relevant information on anything.
> 
> Except to enable us to get closer to the "rescuer must make forwards
> progress" guarantee. In this context, the rescuer is the only
> context we should allow to dip into memory reserves. I'm happy if we
> have to explicitly check for that and set PF_MEMALLOC ourselves 
> (we do that for XFS kernel threads involved in memory reclaim),
> but it's not something we should set automatically on every
> IO completion work item we run....

Ah, okay, that does make sense to me.  Yeah, providing that test
shouldn't be difficult at all.  Lemme cook up a patch.

Thanks.

-- 
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>