On Fri 17-03-17 13:53:33, Peter Zijlstra wrote: > On Fri, Mar 17, 2017 at 08:47:08AM +0100, Michal Hocko wrote: > > On Thu 16-03-17 11:36:21, Tim Chen wrote: > > [...] > > > Perhaps we can only do this expedited exit only when there are idle cpus around. > > > We can use the root sched domain's overload indicator for such a quick check. > > > > This is not so easy, I am afraid. Those CPUs might be idle for a good > > reason (power saving etc.). You will never know by simply checking > > one metric. This is why doing these optimistic parallelization > > optimizations is far from trivial. This is not the first time somebody > > wants to do this. People are trying to make THP migration faster > > doing the similar thing. I guess we really need a help from the > > scheduler to do this properly, though. I've been thinking about an API > > (e.g. try_to_run_in_backgroun) which would evaluate all these nasty > > details and either return with -EBUSY or kick the background thread to > > accomplish the work if the system is reasonably idle. I am not really > > sure whether such an API is viable though. > > > Peter, what do you think? > > Much pain lies this way. I somehow exptected this answer ;) > Also, -enocontext. Well, the context is that there are more users emerging which would like to move some part of the heavy operation (e.g. munmap in exit or THP migration) to the background thread because that operation can be split and parallelized. kworker API is used for this purpose currently and I believe that this is not the right approach because optimization for one workload might be too disruptive on anybody else. On the other side larger machines which would benefit from these optimizations are more likely to have idle CPUs to (ab)use. So the idea was to provide an API which would tell whether kicking a background worker(s) to accomplish the task is feasible. The scheduler sounds like the best candidate to ask this question to me. I might be wrong here of course but a centralized API sounds like a better approach than ad-hoc solutions developed for each particular usecase. -- Michal Hocko SUSE Labs -- 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>
