public inbox for linuxppc-dev@ozlabs.org
 help / color / mirror / Atom feed
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


================================================



  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