On Mon 28-08-17 10:06:11, Tejun Heo wrote: > Hello, Michal. > > On Mon, Aug 28, 2017 at 02:10:56PM +0200, Michal Hocko wrote: > > I am not sure I understand how WQ_HIGHPRI actually helps. The work item > > will get served by a thread with higher priority and from a different > > pool than regular WQs. But what prevents the same issue as described > > above when the highprio pool gets congested? In other words what make > > WQ_HIGHPRI less prone to long stalls when we are under low memory > > situation and new workers cannot be allocated? > > So, the problem wasn't new worker not getting allocated due to memory > pressure. Rescuer can handle that. The problem is that the regular > worker pool is occupied with something which is constantly in runnable > state - most likely writeback / reclaim, so the workqueue doesn't > schedule the other work items. Hmm, we have this in should_reclaim_retry /* * Memory allocation/reclaim might be called from a WQ * context and the current implementation of the WQ * concurrency control doesn't recognize that * a particular WQ is congested if the worker thread is * looping without ever sleeping. Therefore we have to * do a short sleep here rather than calling * cond_resched(). */ if (current->flags & PF_WQ_WORKER) schedule_timeout_uninterruptible(1); And I thought it would be susfficient for kworkers for concurrency WQ congestion thingy to jump in. Or do we need something more generic. E.g. make cond_resched special for kworkers? -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
