linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Jordan <daniel.m.jordan@oracle.com>
To: Andrey Ryabinin <arbn@yandex-team.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: Boris Burkov <boris@bur.io>,
	Bharata B Rao <bharata@linux.vnet.ibm.com>,
	cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andrey Ryabinin <arbn@yandex-team.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/4] cputime,cpuacct: Include guest time in user time in cpuacct.stat
Date: Wed, 17 Mar 2021 18:09:53 -0400	[thread overview]
Message-ID: <87wnu5l9e6.fsf@oracle.com> (raw)
In-Reply-To: <20210217120004.7984-1-arbn@yandex-team.com>

Andrey Ryabinin <arbn@yandex-team.com> writes:

> cpuacct.stat in no-root cgroups shows user time without guest time
> included int it. This doesn't match with user time shown in root
> cpuacct.stat and /proc/<pid>/stat.

Yeah, that's inconsistent.

> Make account_guest_time() to add user time to cgroup's cpustat to
> fix this.

Yep.

cgroup2's cpu.stat is broken the same way for child cgroups, and this
happily fixes it.  Probably deserves a mention in the changelog.

The problem with cgroup2 was, if the workload was mostly guest time,
cpu.stat's user and system together reflected it, but it was split
unevenly across the two.  I think guest time wasn't actually included in
either bucket, it was just that the little user and system time there
was got scaled up in cgroup_base_stat_cputime_show -> cputime_adjust to
match sum_exec_runtime, which did have it.

The stats look ok now for both cgroup1 and 2.  Just slightly unsure
whether we want to change the way both interfaces expose the accounting
in case something out there depends on it.  Seems like we should, but
it'd be good to hear more opinions.

> @@ -148,11 +146,11 @@ void account_guest_time(struct task_struct *p, u64 cputime)
>  
>  	/* Add guest time to cpustat. */
>  	if (task_nice(p) > 0) {
> -		cpustat[CPUTIME_NICE] += cputime;
> -		cpustat[CPUTIME_GUEST_NICE] += cputime;
> +		task_group_account_field(p, CPUTIME_NICE, cputime);
> +		task_group_account_field(p, CPUTIME_GUEST_NICE, cputime);
>  	} else {
> -		cpustat[CPUTIME_USER] += cputime;
> -		cpustat[CPUTIME_GUEST] += cputime;
> +		task_group_account_field(p, CPUTIME_USER, cputime);
> +		task_group_account_field(p, CPUTIME_GUEST, cputime);
>  	}

Makes sense for _USER and _NICE, but it doesn't seem cgroup1 or 2
actually use _GUEST and _GUEST_NICE.

Could go either way.  Consistency is nice, but I probably wouldn't
change the GUEST ones so people aren't confused about why they're
accounted.  It's also extra cycles for nothing, even though most of the
data is probably in the cache.

  parent reply	other threads:[~2021-03-17 22:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17 12:00 [PATCH 1/4] cputime,cpuacct: Include guest time in user time in cpuacct.stat Andrey Ryabinin
2021-02-17 12:00 ` [PATCH 2/4] cgroup: Fix 'usage_usec' time in root's cpu.stat Andrey Ryabinin
2021-03-17 22:13   ` Daniel Jordan
2021-02-17 12:00 ` [PATCH 3/4] sched/cpuacct: fix user/system in shown cpuacct.usage* Andrey Ryabinin
2021-03-17 22:22   ` Daniel Jordan
2021-08-20  9:37     ` Andrey Ryabinin
2021-02-17 12:00 ` [PATCH 4/4] sched/cpuacct: Make user/system times in cpuacct.stat more precise Andrey Ryabinin
2021-03-17 22:25   ` Daniel Jordan
2021-03-17 22:09 ` Daniel Jordan [this message]
2021-08-20  9:37   ` [PATCH 1/4] cputime,cpuacct: Include guest time in user time in cpuacct.stat Andrey Ryabinin
2021-08-20  9:40 ` [PATCH v2 1/5] cputime, cpuacct: " Andrey Ryabinin
2021-08-20  9:40   ` [PATCH v2 2/5] cpuacct: convert BUG_ON() to WARN_ON_ONCE() Andrey Ryabinin
2021-08-20  9:40   ` [PATCH v2 3/5] cgroup: Fix 'usage_usec' time in root's cpu.stat Andrey Ryabinin
2021-08-20  9:40   ` [PATCH v2 4/5] sched/cpuacct: fix user/system in shown cpuacct.usage* Andrey Ryabinin
2021-09-10 19:03     ` Daniel Jordan
2021-08-20  9:40   ` [PATCH v2 5/5] sched/cpuacct: Make user/system times in cpuacct.stat more precise Andrey Ryabinin
2021-09-07 17:19   ` [PATCH v2 1/5] cputime, cpuacct: Include guest time in user time in cpuacct.stat 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=87wnu5l9e6.fsf@oracle.com \
    --to=daniel.m.jordan@oracle.com \
    --cc=arbn@yandex-team.com \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=boris@bur.io \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=cgroups@vger.kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=hannes@cmpxchg.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=stable@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.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;
as well as URLs for NNTP newsgroup(s).