lkml.org 
[lkml]   [2019]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 2/2] mm: Consider subtrees in memory.events
    Hi Tejun,

    On Fri, Jan 25, 2019 at 10:28 AM Tejun Heo <tj@kernel.org> wrote:
    >
    > Hello, Michal.
    >
    > On Fri, Jan 25, 2019 at 06:37:13PM +0100, Michal Hocko wrote:
    > > > What if a user wants to monitor any ooms in the subtree tho, which is
    > > > a valid use case?
    > >
    > > How is that information useful without know which memcg the oom applies
    > > to?
    >
    > For example, a workload manager watching over a subtree for a job with
    > nested memory limits set by the job itself. It wants to take action
    > (reporting and possibly other remediative actions) when something goes
    > wrong in the delegated subtree but isn't involved in how the subtree
    > is configured inside.
    >

    Why not make this configurable at the delegation boundary? As you
    mentioned, there are jobs who want centralized workload manager to
    watch over their subtrees while there can be jobs which want to
    monitor their subtree themselves. For example I can have a job which
    know how to act when one of the children cgroup goes OOM. However if
    the root of that job goes OOM then the centralized workload manager
    should do something about it. With this change, how to implement this
    scenario? How will the central manager differentiates between that a
    subtree of a job goes OOM or the root of that job? I guess from the
    discussion it seems like the centralized manager has to traverse that
    job's subtree to find the source of OOM.

    Why can't we let the implementation of centralized manager easier by
    allowing to configure the propagation of these notifications across
    delegation boundary.

    thanks,
    Shakeel

    \
     
     \ /
      Last update: 2019-01-28 18:30    [W:4.171 / U:0.268 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site