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.

quoted

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>