[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180807175132.GA27979@cmpxchg.org>
Date: Tue, 7 Aug 2018 13:51:32 -0400
From: Johannes Weiner <hannes@...xchg.org>
To: peter enderborg <peter.enderborg@...y.com>
Cc: Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Tejun Heo <tj@...nel.org>,
Suren Baghdasaryan <surenb@...gle.com>,
Daniel Drake <drake@...lessm.com>,
Vinayak Menon <vinmenon@...eaurora.org>,
Christopher Lameter <cl@...ux.com>,
Mike Galbraith <efault@....de>,
Shakeel Butt <shakeelb@...gle.com>, linux-mm@...ck.org,
cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel-team@...com
Subject: Re: [PATCH 0/9] psi: pressure stall information for CPU, memory, and
IO v3
On Tue, Aug 07, 2018 at 01:50:09PM +0200, peter enderborg wrote:
> On 08/01/2018 05:19 PM, Johannes Weiner wrote:
> >
> > A kernel with CONFIG_PSI=y will create a /proc/pressure directory with
> > 3 files: cpu, memory, and io. If using cgroup2, cgroups will also have
> > cpu.pressure, memory.pressure and io.pressure files, which simply
> > aggregate task stalls at the cgroup level instead of system-wide.
> >
> Usually there are objections to add more stuff to /proc. Is this an exception?
It seems like a good fit given that all other system stats of this
type and format are there: loadavg, schedstat, diskstats, uptime etc.
sysfs, and its concept of kernel objects and their attributes, doesn't
really match the type of info exported here. And its breakdown of
complex information into many directories and files can be kind of
tedious to be honest; some information is just more human readable in
a simple table, and still trivial to parse mechanically.
It would also be nice to keep the same file format for both the system
level and cgroups, to avoid having two separate presentations (and two
parsers) for the same type of information at different scopes, but the
sysfs design goals clash with the cgroupfs ones. If we exported the
system stats at the root cgroup level, we'd still need an interface
for !CGROUP systems, and having two ways of reading actually identical
data would again be fairly ugly.
Powered by blists - more mailing lists