All of lore.kernel.org
 help / color / mirror / Atom feed
From: zhengzucheng <zhengzucheng@huawei.com>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>, <mingo@redhat.com>,
	<juri.lelli@redhat.com>, <vincent.guittot@linaro.org>,
	<dietmar.eggemann@arm.com>, <rostedt@goodmis.org>,
	<bsegall@google.com>, <mgorman@suse.de>, <bristot@redhat.com>,
	<vschneid@redhat.com>, <hucool.lihua@huawei.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -next] sched/cputime: Fix the time backward issue about /proc/stat
Date: Sun, 9 Oct 2022 10:28:43 +0800	[thread overview]
Message-ID: <d41afbd5-6040-50ec-c0a5-c52ae48f6515@huawei.com> (raw)
In-Reply-To: <20220930121634.GA266766@lothringen>


在 2022/9/30 20:16, Frederic Weisbecker 写道:
> On Fri, Sep 30, 2022 at 10:43:58AM +0800, zhengzucheng wrote:
>> 在 2022/9/28 20:11, Frederic Weisbecker 写道:
>>> @@ -1024,20 +1045,20 @@ static int kcpustat_cpu_fetch_vtime(struct kernel_cpustat *dst,
>>>    		 * add pending nohz time to the right place.
>>>    		 */
>>>    		if (state == VTIME_SYS) {
>>> -			cpustat[CPUTIME_SYSTEM] += vtime->stime + delta;
>>> +			cpustat[CPUTIME_SYSTEM] += delta;
>>>    		} else if (state == VTIME_USER) {
>>>    			if (task_nice(tsk) > 0)
>>> -				cpustat[CPUTIME_NICE] += vtime->utime + delta;
>>> +				cpustat[CPUTIME_NICE] += delta;
>>>    			else
>>> -				cpustat[CPUTIME_USER] += vtime->utime + delta;
>>> +				cpustat[CPUTIME_USER] += delta;
>> “delta” has the same problem as vtime->utime, which varies with different
>> tasks. switching between different tasks may cause time statistics to be
>> reversed.
> I'm a bit confused, can you provide an example?
Chinese National Day holiday, sorry for not replying to you in time.

CONFIG_HZ=100
const struct kernel_cpustat *src = &kcpustat_cpu(cpu);
struct vtime *vtime = &tsk->vtime;
cpustat[CPUTIME_USER] += vtime->utime + delta;

first:
cat /proc/stat | grep cpu1
cpu1 319 0 496 41665 0 0 0 0 0 0
Task A is running on CPU 1,so vtime is A->vtime and delta is A's delta.
kcpustat_cpu_fetch_vtime: cpu=1 src->cpustat[CPUTIME_USER]=3189000000 
vtime->utime=900000 delta=100001
cpustat[CPUTIME_USER] = 3189000000 + 900000 + 100001 is 3,190,000,001, 
319 ticks

again:
cat /proc/stat | grep cpu1
cpu1 318 0 497 41674 0 0 0 0 0 0
Task B is running on CPU 1,so vtime is B->vtime and delta is B's delta.
kcpustat_cpu_fetch_vtime: cpu=1 src->cpustat[CPUTIME_USER]=3189000000 
vtime->utime=900000 delta=90000
cpustat[CPUTIME_USER] = 3189000000 + 900000 + 90000 is 3,189,990,000, 
318 ticks

The root cause is that the value of task B's "vtime->utime + delta" may 
be smaller than task A.
>
> Thanks.
>
>>>    		} else {
>>>    			WARN_ON_ONCE(state != VTIME_GUEST);
>>>    			if (task_nice(tsk) > 0) {
>>> -				cpustat[CPUTIME_GUEST_NICE] += vtime->gtime + delta;
>>> -				cpustat[CPUTIME_NICE] += vtime->gtime + delta;
>>> +				cpustat[CPUTIME_GUEST_NICE] += delta;
>>> +				cpustat[CPUTIME_NICE] += delta;
>>>    			} else {
>>> -				cpustat[CPUTIME_GUEST] += vtime->gtime + delta;
>>> -				cpustat[CPUTIME_USER] += vtime->gtime + delta;
>>> +				cpustat[CPUTIME_GUEST] += delta;
>>> +				cpustat[CPUTIME_USER] += delta;
>>>    			}
>>>    		}
>>>    	} while (read_seqcount_retry(&vtime->seqcount, seq));
>>> .
> .

  reply	other threads:[~2022-10-09  2:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-28  3:34 [PATCH -next] sched/cputime: Fix the time backward issue about /proc/stat Zucheng Zheng
2022-09-28  8:12 ` Peter Zijlstra
2022-09-28 12:11   ` Frederic Weisbecker
2022-09-30  2:43     ` zhengzucheng
2022-09-30 12:16       ` Frederic Weisbecker
2022-10-09  2:28         ` zhengzucheng [this message]
2022-09-30 12:14 ` [sched/cputime] 131c995687: BUG:spinlock_trylock_failure_on_UP_on_CPU kernel test robot
2022-09-30 12:14   ` kernel test robot

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=d41afbd5-6040-50ec-c0a5-c52ae48f6515@huawei.com \
    --to=zhengzucheng@huawei.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=frederic@kernel.org \
    --cc=hucool.lihua@huawei.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.