[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171219152444.GP3919388@devbig577.frc2.facebook.com>
Date: Tue, 19 Dec 2017 07:24:44 -0800
From: Tejun Heo <tj@...nel.org>
To: Shakeel Butt <shakeelb@...gle.com>
Cc: Michal Hocko <mhocko@...nel.org>, Li Zefan <lizefan@...wei.com>,
Roman Gushchin <guro@...com>,
Vladimir Davydov <vdavydov.dev@...il.com>,
Greg Thelen <gthelen@...gle.com>,
Johannes Weiner <hannes@...xchg.org>,
Hugh Dickins <hughd@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Cgroups <cgroups@...r.kernel.org>, linux-doc@...r.kernel.org
Subject: Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2
Hello,
On Tue, Dec 19, 2017 at 07:12:19AM -0800, Shakeel Butt wrote:
> Yes, there are pros & cons, therefore we should give users the option
> to select the API that is better suited for their use-cases and
Heh, that's not how API decisions should be made. The long term
outcome would be really really bad.
> environment. Both approaches are not interchangeable. We use memsw
> internally for use-cases I mentioned in commit message. This is one of
> the main blockers for us to even consider cgroup-v2 for memory
> controller.
Let's concentrate on the use case. I couldn't quite understand what
was missing from your description. You said that it'd make things
easier for the centralized monitoring system which isn't really a
description of a use case. Can you please go into more details
focusing on the eventual goals (rather than what's currently
implemented)?
Thanks.
--
tejun
Powered by blists - more mailing lists