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

[Tejun Heo <tj@kernel.org>]

Hello, Tetsuo.

On Tue, Aug 29, 2017 at 07:15:05AM +0900, Tetsuo Handa wrote:
> Isn't it any work item which does __GFP_DIRECT_RECLAIM && !__GFP_NORETRY memory
> allocation, for doing __GFP_DIRECT_RECLAIM && !__GFP_NORETRY memory allocation
> burns a lot of CPU cycles under memory pressure? In other words, won't we end up
> with setting WQ_CPU_INTENSIVE to almost all workqueues?

Ah, you're right.  It's the workers getting stuck in direct reclaim.

> > Well, there's one rescuer in the whole system and you'd need
> > nr_online_cpus kthreads if you wanna avoid constant cacheline
> > bouncing.
> 
> Excuse me, one rescuer kernel thread per each WQ_MEM_RECLAIM workqueue, doesn't it?

I meant that it isn't per-cpu.  If you use a kthread for it, that
kthread would be constantly bouncing around.

> My thought is to stop using WQ_MEM_RECLAIM workqueue for mm_percpu_wq and use a
> dedicated kernel thread like oom_reaper. Since the frequency of calling handler
> function seems to be once per a second for each online CPU, I thought switching
> cpumask for NR_CPUS times per a second is tolerable.

Hmm... all these is mostly because workqueue lost the "ignore
concurrency management" flag a while back while converting WQ_HIGHPRI
to mean high nice priority instead of the top of the queue w/o
concurrency management.  Resurrecting that shouldn't be too difficult.
I'll get back to you soon.

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>