Re: + include-linux-sched-mmh-uninline-mmdrop_async-etc.patch added to -mm tree

[Michal Hocko]

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