mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Xunlei Pang <xlpang@linux.alibaba.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/cputime: Ensure correct utime and stime proportion
Date: Tue, 26 Jun 2018 20:19:49 +0800	[thread overview]
Message-ID: <b9363fa9-826f-611f-3ab3-27e50c03422a@linux.alibaba.com> (raw)
In-Reply-To: <20180622071542.61569-1-xlpang@linux.alibaba.com>

On 6/22/18 3:15 PM, Xunlei Pang wrote:
> We use per-cgroup cpu usage statistics similar to "cgroup rstat",
> and encountered a problem that user and sys usages are wrongly
> split sometimes.
> 
> Run tasks with some random run-sleep pattern for a long time, and
> when tick-based time and scheduler sum_exec_runtime hugely drifts
> apart(scheduler sum_exec_runtime is less than tick-based time),
> the current implementation of cputime_adjust() will produce less
> sys usage than the actual use after changing to run a different
> workload pattern with high sys. This is because total tick-based
> utime and stime are used to split the total sum_exec_runtime.
> 
> Same problem exists on utime and stime from "/proc/<pid>/stat".
> 
> [Example]
> Run some random run-sleep patterns for minutes, then change to run
> high sys pattern, and watch.
> 1) standard "top"(which is the correct one):
>    4.6 us, 94.5 sy,  0.0 ni,  0.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
> 2) our tool parsing utime and stime from "/proc/<pid>/stat":
>    20.5 usr, 78.4 sys
> We can see "20.5 usr" displayed in 2) was incorrect, it recovers
> gradually with time: 9.7 usr, 89.5 sys
> 
High sys probably means there's something abnormal on the kernel
path, it may hide issues, so we should make it fairly reliable.
It can easily hit this problem with our per-cgroup statistics.

Hi Peter, any comment on this patch?

  parent reply	other threads:[~2018-06-26 12:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-22  7:15 Xunlei Pang
2018-06-22 10:35 ` kbuild test robot
2018-06-25  8:14   ` Xunlei Pang
2018-06-26 12:19 ` Xunlei Pang [this message]
2018-06-26 15:49   ` Peter Zijlstra
2018-06-27 12:22     ` Xunlei Pang
2018-07-05 10:46       ` Peter Zijlstra
2018-07-05 13:21         ` Xunlei Pang
2018-07-05 13:42           ` Peter Zijlstra
2018-07-05 13:58             ` xunlei
2018-07-09 10:47               ` Peter Zijlstra
2018-07-09  5:52           ` Xunlei Pang
2018-07-09 10:48             ` Peter Zijlstra
2018-07-09 15:00               ` Xunlei Pang
2018-07-02 15:21     ` Tejun Heo
2018-07-04  6:56       ` Xunlei Pang

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=b9363fa9-826f-611f-3ab3-27e50c03422a@linux.alibaba.com \
    --to=xlpang@linux.alibaba.com \
    --cc=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tj@kernel.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

all inboxes | Powered by JetHome®