lkml.org 
[lkml]   [2018]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] mm,oom: Bring OOM notifier callbacks to outside of OOM killer.
    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

    \
     
     \ /
      Last update: 2018-06-28 23:29    [W:5.408 / U:0.472 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site