Thread (48 messages) 48 messages, 6 authors, 2019-02-11

Re: [PATCH 2/2] mm: Consider subtrees in memory.events

From: Shakeel Butt <hidden>
Date: 2019-01-28 16:08:46
Also in: linux-mm, lkml

Hi Tejun,

On Mon, Jan 28, 2019 at 8:05 AM Tejun Heo [off-list ref] wrote:
Hello, Shakeel.

On Mon, Jan 28, 2019 at 07:59:33AM -0800, Shakeel Butt wrote:
quoted
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.
I think the right way to achieve the above would be having separate
recursive and local counters.
Do you envision a separate interface/file for recursive and local
counters? That would make notifications simpler but that is an
additional interface.

Shakeel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help