On Fri 15-09-17 11:05:20, Andrew Morton wrote: > On Fri, 15 Sep 2017 09:12:28 +0200 Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > On Fri 15-09-17 09:07:31, Michal Hocko wrote: > > > On Thu 14-09-17 13:19:38, Andrew Morton wrote: > > > > From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > > > > Subject: include/linux/sched/mm.h: uninline mmdrop_async(), etc > > > > > > > > mmdrop_async() is only used in fork.c. Move that and its support > > > > functions into fork.c, uninline it all. > > > > > > Is this really an improvement? Why do we want to discourage more code > > > paths to use mmdrop_async? It sounds like a useful api and it has been > > > removed only because it lost its own user in oom code. Now that we have > > > a user I would just keep it where it was before. > > > > Dohh, I have mixed mmput_async with mmdrop_async. Anyway I still think > > that this is universal enough to have it in a header rather than hiding > > it in fork.c > > Async free is a hack. It consumes more resources (runtime and memory) > than a synchronous free. It introduces a risk of memory exhaustion > when an unbounded number of async frees are pending, not yet serviced. > It introduces a risk of unbounded latency when an unbounded number of > async frees are serviced by the kernel thread. It is our standard technique of postponing an action to a more relaxed context when we cannot afford an action from the current context. > Synchronous frees are simply better, so we shouldn't encourage the use > of async frees. No questions about that. But we have a clear demand for the deferred implementation as well. And we have learned that having our own private, thing usually leads people to invent their own wheel. -- 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>
