Hello, Tetsuo. I went through the logs and it doesn't look like the mm workqueue actually stalled, it was just slow to make progress. Please see below. On Fri, Jul 07, 2017 at 07:27:06PM +0900, Tetsuo Handa wrote: > Since drain_local_pages_wq work was stalling for 144 seconds as of uptime = 541, > drain_local_pages_wq work was queued around uptime = 397 (which is about 6 seconds > since the OOM killer/reaper reclaimed some memory for the last time). > > But as far as I can see from traces, the mm_percpu_wq thread as of uptime = 444 was > idle, while drain_local_pages_wq work was pending from uptime = 541 to uptime = 605. > This means that the mm_percpu_wq thread did not start processing drain_local_pages_wq > work immediately. (I don't know what made drain_local_pages_wq work be processed.) > > Why? Is this a workqueue implementation bug? Is this a workqueue usage bug? So, rescuer doesn't kick as soon as the workqueue becomes slow. It kicks in if the worker pool that the workqueue is associated with hangs. That is, if you have other work items actively running, e.g., for reclaim on the pool, the pool isn't stalled and rescuers won't be woken up. IOW, having a rescuer prevents a workqueue from deadlocking due to resource starvation but it doesn't necessarily make it go faster. It's a deadlock prevention mechanism, not a priority raising one. If the work items need preferential execution, it should use WQ_HIGHPRI. 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>
