lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ