[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190130165058.GA18811@dhcp22.suse.cz>
Date: Wed, 30 Jan 2019 17:50:58 +0100
From: Michal Hocko <mhocko@...nel.org>
To: Tejun Heo <tj@...nel.org>
Cc: Johannes Weiner <hannes@...xchg.org>,
Chris Down <chris@...isdown.name>,
Andrew Morton <akpm@...ux-foundation.org>,
Roman Gushchin <guro@...com>, Dennis Zhou <dennis@...nel.org>,
linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
linux-mm@...ck.org, kernel-team@...com
Subject: Re: [PATCH 2/2] mm: Consider subtrees in memory.events
On Tue 29-01-19 06:52:40, Tejun Heo wrote:
> Hello,
>
> On Tue, Jan 29, 2019 at 03:43:06PM +0100, Michal Hocko wrote:
> > All memcg events are represented non-hierarchical AFAICS
> > memcg_memory_event() simply accounts at the level when it happens. Or do
> > I miss something? Or are you talking about .events files for other
> > controllers?
>
> Yeah, cgroup.events and .stat files as some of the local stats would
> be useful too, so if we don't flip memory.events we'll end up with sth
> like cgroup.events.local, memory.events.tree and memory.stats.local,
> which is gonna be hilarious.
Why cannot we simply have memory.events_tree and be done with it? Sure
the file names are not goin to be consistent which is a minus but that
ship has already sailed some time ago.
> If you aren't willing to change your mind, the only option seems to be
> introducing a mount option to gate the flip and additions of local
> files. Most likely, userspace will enable the option by default
> everywhere, so the end result will be exactly the same but I guess
> it'll better address your concern.
How does the consumer of the API learns about the mount type?
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists