Skip to content
  • Shakeel Butt's avatar
    mm, memcg: introduce memory.events.local · 1e577f97
    Shakeel Butt authored
    The memory controller in cgroup v2 exposes memory.events file for each
    memcg which shows the number of times events like low, high, max, oom
    and oom_kill have happened for the whole tree rooted at that memcg.
    Users can also poll or register notification to monitor the changes in
    that file.  Any event at any level of the tree rooted at memcg will
    notify all the listeners along the path till root_mem_cgroup.  There are
    existing users which depend on this behavior.
    
    However there are users which are only interested in the events
    happening at a specific level of the memcg tree and not in the events in
    the underlying tree rooted at that memcg.  One such use-case is a
    centralized resource monitor which can dynamically adjust the limits of
    the jobs running on a system.  The jobs can create their sub-hierarchy
    for their own sub-tasks.  The centralized monitor is only interested in
    the events at the top level memcgs of the jobs as it can then act and
    adjust the limits of the jobs.  Using the current memory.events for such
    centralized monitor is very inconvenient.  The monitor will keep
    receiving events which it is not interested and to find if the received
    event is interesting, it has to read memory.event files of the next
    level and compare it with the top level one.  So, let's introduce
    memory.events.local to the memcg which shows and notify for the events
    at the memcg level.
    
    Now, does memory.stat and memory.pressure need their local versions.  IMHO
    no due to the no internal process contraint of the cgroup v2.  The
    memory.stat file of the top level memcg of a job shows the stats and
    vmevents of the whole tree.  The local stats or vmevents of the top level
    memcg will only change if there is a process running in that memcg but v2
    does not allow that.  Similarly for memory.pressure there will not be any
    process in the internal nodes and thus no chance of local pressure.
    
    Link: http://lkml.kernel.org/r/20190527174643.209172-1-shakeelb@google.com
    
    
    Signed-off-by: default avatarShakeel Butt <shakeelb@google.com>
    Reviewed-by: default avatarRoman Gushchin <guro@fb.com>
    Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
    Acked-by: default avatarMichal Hocko <mhocko@suse.com>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Chris Down <chris@chrisdown.name>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    1e577f97