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 from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
