Re: [PATCH] mm,oom: Bring OOM notifier callbacks to outside of OOM killer.

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Thu, Jun 28, 2018 at 01:39:42PM +0200, Michal Hocko wrote:
> On Wed 27-06-18 07:31:25, Paul E. McKenney wrote:
> > On Wed, Jun 27, 2018 at 09:22:07AM +0200, Michal Hocko wrote:
> > > On Tue 26-06-18 10:03:45, Paul E. McKenney wrote:
> > > [...]
> > > > 3.	Something else?
> > > 
> > > How hard it would be to use a different API than oom notifiers? E.g. a
> > > shrinker which just kicks all the pending callbacks if the reclaim
> > > priority reaches low values (e.g. 0)?
> > 
> > Beats me.  What is a shrinker?  ;-)
> 
> This is a generich mechanism to reclaim memory that is not on standard
> LRU lists. Lwn.net surely has some nice coverage (e.g.
> https://lwn.net/Articles/548092/).

"In addition, there is little agreement over what a call to a shrinker
really means or how the called subsystem should respond."  ;-)

Is this set up using register_shrinker() in mm/vmscan.c?  I am guessing
that the many mentions of shrinker in DRM are irrelevant.

If my guess is correct, the API seems a poor fit for RCU.  I can
produce an approximate number of RCU callbacks for ->count_objects(),
but a given callback might free a lot of memory or none at all.  Plus,
to actually have ->scan_objects() free them before returning, I would
need to use something like rcu_barrier(), which might involve longer
delays than desired.

Or am I missing something here?

> > More seriously, could you please point me at an exemplary shrinker
> > use case so I can see what is involved?
> 
> Well, I am not really sure what is the objective of the oom notifier to
> point you to the right direction. IIUC you just want to kick callbacks
> to be handled sooner under a heavy memory pressure, right? How is that
> achieved? Kick a worker?

That is achieved by enqueuing a non-lazy callback on each CPU's callback
list, but only for those CPUs having non-empty lists.  This causes
CPUs with lists containing only lazy callbacks to be more aggressive,
in particular, it prevents such CPUs from hanging out idle for seconds
at a time while they have callbacks on their lists.

The enqueuing happens via an IPI to the CPU in question.

						Thanx, Paul