From: Shrikanth Hegde <sshegde@linux.ibm.com>
To: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
Frederic Weisbecker <frederic@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
Ben Segall <bsegall@google.com>,
Boqun Feng <boqun.feng@gmail.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
Joel Fernandes <joelagnelf@nvidia.com>,
Juri Lelli <juri.lelli@redhat.com>,
Kieran Bingham <kbingham@kernel.org>,
Mel Gorman <mgorman@suse.de>,
Michael Ellerman <mpe@ellerman.id.au>,
Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
Nicholas Piggin <npiggin@gmail.com>,
"Paul E . McKenney" <paulmck@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Sven Schnelle <svens@linux.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Uladzislau Rezki <urezki@gmail.com>,
Valentin Schneider <vschneid@redhat.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Xin Zhao <jackzxcui1989@163.com>,
linux-pm@vger.kernel.org, linux-s390@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 04/15] powerpc/time: Prepare to stop elapsing in dynticks-idle
Date: Wed, 25 Feb 2026 19:03:16 +0530 [thread overview]
Message-ID: <729a7e7f-a50e-480c-87ce-c45221fbb326@linux.ibm.com> (raw)
In-Reply-To: <a0c6e65c-3331-402a-94eb-14ba7f4b7ba7@kernel.org>
On 2/25/26 4:44 PM, Christophe Leroy (CS GROUP) wrote:
> Hi Hegde,
>
> Le 25/02/2026 à 11:34, Shrikanth Hegde a écrit :
>> Hi Christophe.
>>
>> On 2/25/26 3:15 PM, Christophe Leroy (CS GROUP) wrote:
>>>
>>> Hope it is more explicit now.
>>>
>>
>> Got it. The main concern was around with additional computation that
>> sched_clock,
>> not any additional paths per se.
>>
>> yes, that would be possible,
>>
>>
>> How about we do below? This adds only one subtraction.
>> This achieves the same outcome.
>
> It adds a bit more than just a substration. It adds a call to an extern
> fonction.
I think we should make it always inline and move it to time.h
>
> 00000164 <my_account_cpu_user_entry>:
> 164: 94 21 ff f0 stwu r1,-16(r1)
> 168: 7c 08 02 a6 mflr r0
> 16c: 90 01 00 14 stw r0,20(r1)
> 170: 93 e1 00 0c stw r31,12(r1)
> 174: 7f ec 42 e6 mftb r31
> 178: 48 00 00 01 bl 178 <my_account_cpu_user_entry+0x14>
> 178: R_PPC_REL24 get_boot_tb
> 17c: 81 02 00 08 lwz r8,8(r2)
> 180: 81 22 00 28 lwz r9,40(r2)
> 184: 7c 84 f8 50 subf r4,r4,r31
> 188: 7d 29 40 50 subf r9,r9,r8
> 18c: 7d 29 22 14 add r9,r9,r4
> 190: 90 82 00 24 stw r4,36(r2)
> 194: 91 22 00 08 stw r9,8(r2)
> 198: 80 01 00 14 lwz r0,20(r1)
> 19c: 83 e1 00 0c lwz r31,12(r1)
> 1a0: 7c 08 03 a6 mtlr r0
> 1a4: 38 21 00 10 addi r1,r1,16
> 1a8: 4e 80 00 20 blr
>
> 000001ac <my_account_cpu_user_exit>:
> 1ac: 94 21 ff f0 stwu r1,-16(r1)
> 1b0: 7c 08 02 a6 mflr r0
> 1b4: 90 01 00 14 stw r0,20(r1)
> 1b8: 93 e1 00 0c stw r31,12(r1)
> 1bc: 7f ec 42 e6 mftb r31
> 1c0: 48 00 00 01 bl 1c0 <my_account_cpu_user_exit+0x14>
> 1c0: R_PPC_REL24 get_boot_tb
> 1c4: 81 02 00 0c lwz r8,12(r2)
> 1c8: 81 22 00 24 lwz r9,36(r2)
> 1cc: 7c 84 f8 50 subf r4,r4,r31
> 1d0: 7d 29 40 50 subf r9,r9,r8
> 1d4: 7d 29 22 14 add r9,r9,r4
> 1d8: 90 82 00 28 stw r4,40(r2)
> 1dc: 91 22 00 0c stw r9,12(r2)
> 1e0: 80 01 00 14 lwz r0,20(r1)
> 1e4: 83 e1 00 0c lwz r31,12(r1)
> 1e8: 7c 08 03 a6 mtlr r0
> 1ec: 38 21 00 10 addi r1,r1,16
> 1f0: 4e 80 00 20 blr
>
>
> I really still can't see the point of this substraction.
>
> At one place we do
>
> tb1 = mftb1;
>
> acct->utime += (tb1 - acct->starttime_user);
> acct->starttime = tb1;
>
> At the other place we do
>
> tb2 = mftb2;
>
> acct->stime += (tb2 - acct->starttime);
> acct->starttime_user = tb2;
>
> So at the end we have
>
> acct->utime += mftb1 - mftb2;
> acct->stime += mftb2 - mftb1;
>
> You want to change to
> tb1 = mftb1 - boot_tb;
> tb2 = mftb2 - boot_tb;
>
> At the end we would get
>
> acct->utime += mftb1 - boot_tb - mftb2 + boot_tb = mftb1 - mftb2;
> acct->stime += mftb2 - boot_tb - mftb1 + boot_tb = mftb2 - mftb1;
>
> So what's the point in doing such a useless substract that disappears at
> the end ? What am I missing ?
>
I had similar thought, but I saw this data below when i do exec on the system.
This was the stats seen on PowerNV system with 144 CPUs.
Nothing is running on the system after boot. So it is mostly idle.
======== With the series applied ===
cat /proc/stat | head
cpu 1494 0 135607576 9628633227 16876 142 63 0 0 0
cpu0 0 0 8 67807311 0 2 40 0 0 0
cpu1 0 0 6 67807349 0 0 0 0 0 0
cat /proc/uptime
48.32 96286332.82 << Note this value is too huge. Also system value is also huge.
========= without the series(tip/master) ===============
cat /proc/stat | head
cpu 2003 0 67866261 859414 15923 249 66 0 0 0
cpu0 5 0 23 5595 461 2 38 0 0 0
cpu1 0 0 9 6092 21 0 3 0 0 0
cat /proc/uptime
61.29 8594.82 << This is right. 144*61 = 8784.
But note, the system time reported. i.e 67866261. It is too huge again. And very close to actual mftb value
rather than the diff. i.e we have paths were tb1 is not done. tb2 is effectively mftb - 0
========= with proposed fix of mftb - boot_tb ===============
cat /proc/stat | head
cpu 5187 0 10996 2025690 16566 765 184 0 0 0
cpu0 9 0 28 14096 65 6 108 0 0 0
cpu1 4 0 15 14277 0 0 2 0 0 0
cat /proc/uptime
142.97 20257.42 << Looks correct, since 142*144 is close to 20448
=============================================================
Now lets go to CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
cat /proc/stat | head
cpu 1804 0 3003 791760 15695 0 0 0 0 0
cpu0 22 0 46 5535 0 0 0 0 0 0
cpu1 0 0 7 5637 0 0 0 0 0 0
cat /proc/uptime
56.49 7918.05 << Looks correct. close 56*144
================================================
next prev parent reply other threads:[~2026-02-25 13:33 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 14:22 [PATCH 00/15 v2] tick/sched: Refactor idle cputime accounting Frederic Weisbecker
2026-02-06 14:22 ` [PATCH 01/15] sched/idle: Handle offlining first in idle loop Frederic Weisbecker
2026-02-18 18:22 ` Shrikanth Hegde
2026-02-06 14:22 ` [PATCH 02/15] sched/cputime: Remove superfluous and error prone kcpustat_field() parameter Frederic Weisbecker
2026-02-18 18:25 ` Shrikanth Hegde
2026-02-06 14:22 ` [PATCH 03/15] sched/cputime: Correctly support generic vtime idle time Frederic Weisbecker
2026-02-06 14:22 ` [PATCH 04/15] powerpc/time: Prepare to stop elapsing in dynticks-idle Frederic Weisbecker
2026-02-19 18:30 ` Shrikanth Hegde
2026-02-24 15:41 ` Christophe Leroy (CS GROUP)
2026-02-25 7:46 ` Shrikanth Hegde
2026-02-25 9:45 ` Christophe Leroy (CS GROUP)
2026-02-25 10:34 ` Shrikanth Hegde
2026-02-25 11:14 ` Christophe Leroy (CS GROUP)
2026-02-25 13:33 ` Shrikanth Hegde [this message]
2026-02-25 13:54 ` Christophe Leroy (CS GROUP)
2026-02-25 17:47 ` Shrikanth Hegde
2026-02-25 17:59 ` Christophe Leroy (CS GROUP)
2026-02-26 4:06 ` Shrikanth Hegde
2026-02-26 7:32 ` Christophe Leroy (CS GROUP)
2026-02-26 12:57 ` Shrikanth Hegde
2026-02-06 14:22 ` [PATCH 05/15] s390/time: " Frederic Weisbecker
2026-02-06 14:22 ` [PATCH 06/15] tick/sched: Unify idle cputime accounting Frederic Weisbecker
2026-02-06 14:22 ` [PATCH 07/15] cpufreq: ondemand: Simplify idle cputime granularity test Frederic Weisbecker
2026-02-06 14:22 ` [PATCH 08/15] tick/sched: Remove nohz disabled special case in cputime fetch Frederic Weisbecker
2026-02-06 14:22 ` [PATCH 09/15] tick/sched: Move dyntick-idle cputime accounting to cputime code Frederic Weisbecker
2026-02-06 14:22 ` [PATCH 10/15] tick/sched: Remove unused fields Frederic Weisbecker
2026-02-06 14:22 ` [PATCH 11/15] tick/sched: Account tickless idle cputime only when tick is stopped Frederic Weisbecker
2026-02-06 14:22 ` [PATCH 12/15] tick/sched: Consolidate idle time fetching APIs Frederic Weisbecker
2026-02-06 22:35 ` Frederic Weisbecker
2026-02-06 14:22 ` [PATCH 13/15] sched/cputime: Provide get_cpu_[idle|iowait]_time_us() off-case Frederic Weisbecker
2026-02-06 14:22 ` [PATCH 14/15] sched/cputime: Handle idle irqtime gracefully Frederic Weisbecker
2026-03-03 11:11 ` Shrikanth Hegde
2026-03-20 14:32 ` Frederic Weisbecker
2026-02-06 14:22 ` [PATCH 15/15] sched/cputime: Handle dyntick-idle steal time correctly Frederic Weisbecker
2026-03-03 11:17 ` Shrikanth Hegde
2026-03-24 14:53 ` Frederic Weisbecker
2026-02-11 13:43 ` [PATCH 00/15 v2] tick/sched: Refactor idle cputime accounting Shrikanth Hegde
2026-02-11 17:06 ` Frederic Weisbecker
2026-02-12 7:02 ` Shrikanth Hegde
2026-02-18 18:11 ` Shrikanth Hegde
-- strict thread matches above, loose matches on Subject: below --
2026-01-16 14:51 [PATCH 00/15] " Frederic Weisbecker
2026-01-16 14:51 ` [PATCH 04/15] powerpc/time: Prepare to stop elapsing in dynticks-idle Frederic Weisbecker
2026-02-25 17:53 ` Christophe Leroy (CS GROUP)
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=729a7e7f-a50e-480c-87ce-c45221fbb326@linux.ibm.com \
--to=sshegde@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=anna-maria@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=borntraeger@linux.ibm.com \
--cc=bsegall@google.com \
--cc=chleroy@kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=frederic@kernel.org \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jackzxcui1989@163.com \
--cc=jan.kiszka@siemens.com \
--cc=joelagnelf@nvidia.com \
--cc=juri.lelli@redhat.com \
--cc=kbingham@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=neeraj.upadhyay@kernel.org \
--cc=npiggin@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=svens@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox