Re: [PATCH] mm: Use WQ_HIGHPRI for mm_percpu_wq.

[Tejun Heo <tj@kernel.org>]

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@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>