public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Li Zefan <lizefan@huawei.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Ingo Molnar <mingo@redhat.com>, Roman Gushchin <guro@fb.com>,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
	kernel-team@fb.com
Subject: Re: [PATCH cgroup/for-4.15] cgroup, sched: Move basic cpu stats from cgroup.stat to cpu.stat
Date: Tue, 24 Oct 2017 07:59:15 -0700	[thread overview]
Message-ID: <20171024145915.GC8598@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <20171024083504.GM3165@worktop.lehotels.local>

Hello, Peter.

On Tue, Oct 24, 2017 at 10:35:04AM +0200, Peter Zijlstra wrote:
> > The more I think about showing cpu stat in cgroup.stat, the uglier it
> > seems. 
> 
> I've not been paying much attention to this, could you elaborate on the
> problems there?

Sure, so, on cgroup2, the basic stat collects cpu usage info whether
cpu controller is enabled or not.  As the hot path overhead is always
per-cpu and constant, there's no reason to not to and always having
the information is useful, especially as enabling cpu isn't free of
side-effects.  This is similar to what cpuacct did in cgroup1 but
cgroup2's single hierarchy makes the dedicated controller unnecessary.

The issue at hand with this patch is how the stat is presented when
the controller is not enabled.  There were two alternatives.

1. Make it available in the core file cgroup.stat with subsystem
   prefix ("cpu." for cpu).

   This is easy to implement but a bit ugly because when the
   controller is enabled, the same information is available in two
   places - cgroup.stat and cpu.stat.  Access from userspace becomes
   ugly too especially in cases where we make more fields available in
   basic stat.

2. Make $SUBSYS.stat available whether the controller is enabled or
   not.  Show the basic stat when the controller is disabled, show the
   full thing when enabled.

   This is somewhat more complicated to implement and having a
   subsystem specific file around when the controller is not enabled
   might be a bit confusing.  However, it ensures that a given piece
   of information is available in only one place and makes it less
   awkward to make more information available through basic stat.

The original implementation went for #1 and this patch switches it to
#2.

> > This patch flips it so that "cpu.stat" is always available
> > with basic cpu stat instead.  It only changes the presentation and
> > changes to the scheduler code is minimal.  Will route with the other
> > cpu controller changes through cgroup/for-4.15 unless there are
> > objections.
> 
> And this is -v2 only? I'm a little lost on how all that connects.

Yeap, basic stat is v2 only.  We can't do it against multiple
hierarchies with constant overhead.

Thanks.

-- 
tejun

  reply	other threads:[~2017-10-24 14:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-23 23:18 [PATCH cgroup/for-4.15] cgroup, sched: Move basic cpu stats from cgroup.stat to cpu.stat Tejun Heo
2017-10-24  8:35 ` Peter Zijlstra
2017-10-24 14:59   ` Tejun Heo [this message]
2017-10-26 17:43 ` Peter Zijlstra
2017-10-26 17:57 ` Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171024145915.GC8598@devbig577.frc2.facebook.com \
    --to=tj@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox