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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
