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. Setting WQ_HIGHPRI works as highpri worker pool isn't likely to be contended that way but might not be the best solution. The right thing to do would be setting WQ_CPU_INTENSIVE on the work items which can burn a lot of CPU cycles so that it doesn't get in the way of other work items (workqueue should probably trigger a warning on these work items too). Tetuso, can you please try to find which work items are occupying the worker pool for an extended period time under memory pressure and set WQ_CPU_INTENSIVE on them? > > If we do want to make > > sure that work items on mm_percpu_wq workqueue are executed without delays, > > we need to consider using kthread_workers instead of workqueue. (Or, maybe > > somehow we can share one kthread with constantly manipulating cpumask?) > > Hmm, that doesn't sound like a bad idea to me. We already have a rescuer > thread that basically sits idle all the time so having a dedicated > kernel thread will not be more expensive wrt. resources. So I think this > is a more reasonable approach than playing with WQ_HIGHPRI which smells > like a quite obscure workaround than a real fix to me. Well, there's one rescuer in the whole system and you'd need nr_online_cpus kthreads if you wanna avoid constant cacheline bouncing. Thanks. -- tejun -- 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>
