[PATCH] powerpc/vtime: Initialize starttime at boot for native accounting

[PATCH] powerpc/vtime: Initialize starttime at boot for native accounting

[Shrikanth Hegde]

It was observed that /proc/stat had very large value for one ore more
CPUs. It was more visible after recent code simplifications around
cpustats.

System has 240 CPUs.

cat /proc/uptime;
194.18 46500.55
cat /proc/stat
cpu  5966 39 837032887 4650070 164 185 100 0 0 0
cpu0 108 0 837030890 19109 24 4 23 0 0 0

Since uptime is 194s, system time of each CPU can't be more than 19400.
Sum of system time  of all CPUs can't be more than 19400*240 4656000.
In fact huge value is close to mftb(). Note mftb doesn't reset on powerVM
when the LPAR restart. It only resets when whole system resets. The same
issue exists for kexec too.

This happens since starttime is not setup at init time. Once it is set
then subsequent vtime_delta will return the right delta. 

Fix it by initializing the starttime during CPU initialization. This
fixes the large times seen.

cat /proc/uptime; cat /proc/stat
15.78 3694.63
cpu  6035 35 1347 369479 23 144 49 0 0 0
cpu0 19 0 38 1508 0 1 14 0 0 0

Now, system time is reported as expected.

Suggested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
---

Christophe, I have taken the patch as is from the discussion we had.
Let me know if i should send it with your signed-off-by tag. I have just
written the changelog. I sent it like this since tag was not there.

discussion thread:
https://lore.kernel.org/all/cd10be19-e0bc-4e0c-8dac-4f1c05d0de8f@kernel.org/

Also, does this warrant Fixes tag? I found these two likely candidates.
Likely this issues exists since beginning.
c223c90386bc powerpc32: provide VIRT_CPU_ACCOUNTING
b38a181c11d0 powerpc/time: isolate scaled cputime accounting in dedicated functions.

 arch/powerpc/kernel/time.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 3460d1a5a97c..11145c40183d 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -377,7 +377,6 @@ void vtime_task_switch(struct task_struct *prev)
 	}
 }
 
-#ifdef CONFIG_NO_HZ_COMMON
 /**
  * vtime_reset - Fast forward vtime entry clocks
  *
@@ -394,6 +393,7 @@ void vtime_reset(void)
 #endif
 }
 
+#ifdef CONFIG_NO_HZ_COMMON
 /**
  * vtime_dyntick_start - Inform vtime about entry to idle-dynticks
  *
@@ -933,6 +933,7 @@ static void __init set_decrementer_max(void)
 static void __init init_decrementer_clockevent(void)
 {
 	register_decrementer_clockevent(smp_processor_id());
+	vtime_reset();
 }
 
 void secondary_cpu_time_init(void)
@@ -948,6 +949,7 @@ void secondary_cpu_time_init(void)
 	/* FIME: Should make unrelated change to move snapshot_timebase
 	 * call here ! */
 	register_decrementer_clockevent(smp_processor_id());
+	vtime_reset();
 }
 
 /*
-- 
2.47.3

Re: [PATCH] powerpc/vtime: Initialize starttime at boot for native accounting

[Christophe Leroy (CS GROUP)]

Le 04/06/2026 à 15:24, Shrikanth Hegde a écrit :
> It was observed that /proc/stat had very large value for one ore more
> CPUs. It was more visible after recent code simplifications around
> cpustats.
> 
> System has 240 CPUs.
> 
> cat /proc/uptime;
> 194.18 46500.55
> cat /proc/stat
> cpu  5966 39 837032887 4650070 164 185 100 0 0 0
> cpu0 108 0 837030890 19109 24 4 23 0 0 0
> 
> Since uptime is 194s, system time of each CPU can't be more than 19400.
> Sum of system time  of all CPUs can't be more than 19400*240 4656000.
> In fact huge value is close to mftb(). Note mftb doesn't reset on powerVM
> when the LPAR restart. It only resets when whole system resets. The same
> issue exists for kexec too.
> 
> This happens since starttime is not setup at init time. Once it is set
> then subsequent vtime_delta will return the right delta.
> 
> Fix it by initializing the starttime during CPU initialization. This
> fixes the large times seen.
> 
> cat /proc/uptime; cat /proc/stat
> 15.78 3694.63
> cpu  6035 35 1347 369479 23 144 49 0 0 0
> cpu0 19 0 38 1508 0 1 14 0 0 0
> 
> Now, system time is reported as expected.
> 
> Suggested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>

Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>

> ---
> 
> Christophe, I have taken the patch as is from the discussion we had.
> Let me know if i should send it with your signed-off-by tag. I have just
> written the changelog. I sent it like this since tag was not there.

Suggested-by is fine for me.

> 
> discussion thread:
> https://lore.kernel.org/all/cd10be19-e0bc-4e0c-8dac-4f1c05d0de8f@kernel.org/
> 
> Also, does this warrant Fixes tag? I found these two likely candidates.
> Likely this issues exists since beginning.
> c223c90386bc powerpc32: provide VIRT_CPU_ACCOUNTING

You say system has 240 CPU so I suppose this is not ppc32. That commit 
wsa not supposed to change anything for ppc64, did you identify anything 
special in that commit related to ppc64 ?

> b38a181c11d0 powerpc/time: isolate scaled cputime accounting in dedicated functions.

This one is also pure code re-organisation, unless you've been able to 
spot a particular issue ?

> 
>   arch/powerpc/kernel/time.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 3460d1a5a97c..11145c40183d 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -377,7 +377,6 @@ void vtime_task_switch(struct task_struct *prev)
>   	}
>   }
>   
> -#ifdef CONFIG_NO_HZ_COMMON
>   /**
>    * vtime_reset - Fast forward vtime entry clocks
>    *
> @@ -394,6 +393,7 @@ void vtime_reset(void)
>   #endif
>   }
>   
> +#ifdef CONFIG_NO_HZ_COMMON
>   /**
>    * vtime_dyntick_start - Inform vtime about entry to idle-dynticks
>    *
> @@ -933,6 +933,7 @@ static void __init set_decrementer_max(void)
>   static void __init init_decrementer_clockevent(void)
>   {
>   	register_decrementer_clockevent(smp_processor_id());
> +	vtime_reset();
>   }
>   
>   void secondary_cpu_time_init(void)
> @@ -948,6 +949,7 @@ void secondary_cpu_time_init(void)
>   	/* FIME: Should make unrelated change to move snapshot_timebase
>   	 * call here ! */
>   	register_decrementer_clockevent(smp_processor_id());
> +	vtime_reset();
>   }
>   
>   /*

Re: [PATCH] powerpc/vtime: Initialize starttime at boot for native accounting

[Christophe Leroy (CS GROUP)]

Le 04/06/2026 à 16:51, Christophe Leroy (CS GROUP) a écrit :
> 
> 
> Le 04/06/2026 à 15:24, Shrikanth Hegde a écrit :
>> It was observed that /proc/stat had very large value for one ore more
>> CPUs. It was more visible after recent code simplifications around
>> cpustats.
>>
>> System has 240 CPUs.
>>
>> cat /proc/uptime;
>> 194.18 46500.55
>> cat /proc/stat
>> cpu  5966 39 837032887 4650070 164 185 100 0 0 0
>> cpu0 108 0 837030890 19109 24 4 23 0 0 0
>>
>> Since uptime is 194s, system time of each CPU can't be more than 19400.
>> Sum of system time  of all CPUs can't be more than 19400*240 4656000.
>> In fact huge value is close to mftb(). Note mftb doesn't reset on powerVM
>> when the LPAR restart. It only resets when whole system resets. The same
>> issue exists for kexec too.
>>
>> This happens since starttime is not setup at init time. Once it is set
>> then subsequent vtime_delta will return the right delta.
>>
>> Fix it by initializing the starttime during CPU initialization. This
>> fixes the large times seen.
>>
>> cat /proc/uptime; cat /proc/stat
>> 15.78 3694.63
>> cpu  6035 35 1347 369479 23 144 49 0 0 0
>> cpu0 19 0 38 1508 0 1 14 0 0 0
>>
>> Now, system time is reported as expected.
>>
>> Suggested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
>> Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
> 
> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> 
>> ---
>>
>> Christophe, I have taken the patch as is from the discussion we had.
>> Let me know if i should send it with your signed-off-by tag. I have just
>> written the changelog. I sent it like this since tag was not there.
> 
> Suggested-by is fine for me.
> 
>>
>> discussion thread:
>> https://eur01.safelinks.protection.outlook.com/? 
>> url=https%3A%2F%2Flore.kernel.org%2Fall%2Fcd10be19- 
>> e0bc-4e0c-8dac-4f1c05d0de8f%40kernel.org%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C1702c7a5ff63417da4ef08dec248be1d%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639161814851391682%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DjLhS3imHryT613JPVG0mnkWjILSGGrt1tLvmqFHtVM%3D&reserved=0
>>
>> Also, does this warrant Fixes tag? I found these two likely candidates.
>> Likely this issues exists since beginning.
>> c223c90386bc powerpc32: provide VIRT_CPU_ACCOUNTING
> 
> You say system has 240 CPU so I suppose this is not ppc32. That commit 
> wsa not supposed to change anything for ppc64, did you identify anything 
> special in that commit related to ppc64 ?
> 
>> b38a181c11d0 powerpc/time: isolate scaled cputime accounting in 
>> dedicated functions.
> 
> This one is also pure code re-organisation, unless you've been able to 
> spot a particular issue ?

Maybe commit cf9efce0ce31 ("powerpc: Account time using timebase rather 
than PURR")

It removed snapshot_timebases() and I can't see anything to replace it.


> 
>>
>>   arch/powerpc/kernel/time.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
>> index 3460d1a5a97c..11145c40183d 100644
>> --- a/arch/powerpc/kernel/time.c
>> +++ b/arch/powerpc/kernel/time.c
>> @@ -377,7 +377,6 @@ void vtime_task_switch(struct task_struct *prev)
>>       }
>>   }
>> -#ifdef CONFIG_NO_HZ_COMMON
>>   /**
>>    * vtime_reset - Fast forward vtime entry clocks
>>    *
>> @@ -394,6 +393,7 @@ void vtime_reset(void)
>>   #endif
>>   }
>> +#ifdef CONFIG_NO_HZ_COMMON
>>   /**
>>    * vtime_dyntick_start - Inform vtime about entry to idle-dynticks
>>    *
>> @@ -933,6 +933,7 @@ static void __init set_decrementer_max(void)
>>   static void __init init_decrementer_clockevent(void)
>>   {
>>       register_decrementer_clockevent(smp_processor_id());
>> +    vtime_reset();
>>   }
>>   void secondary_cpu_time_init(void)
>> @@ -948,6 +949,7 @@ void secondary_cpu_time_init(void)
>>       /* FIME: Should make unrelated change to move snapshot_timebase
>>        * call here ! */
>>       register_decrementer_clockevent(smp_processor_id());
>> +    vtime_reset();
>>   }
>>   /*
> 

Re: [PATCH] powerpc/vtime: Initialize starttime at boot for native accounting

[Shrikanth Hegde]

Hi Christophe. Thanks for taking a look and review.

On 6/4/26 8:42 PM, Christophe Leroy (CS GROUP) wrote:
> 

>>> Also, does this warrant Fixes tag? I found these two likely candidates.
>>> Likely this issues exists since beginning.
>>> c223c90386bc powerpc32: provide VIRT_CPU_ACCOUNTING
>>
>> You say system has 240 CPU so I suppose this is not ppc32. That commit 
>> wsa not supposed to change anything for ppc64, did you identify 
>> anything special in that commit related to ppc64 ?

Yes. this was ppc64.

>>
>>> b38a181c11d0 powerpc/time: isolate scaled cputime accounting in 
>>> dedicated functions.
>>
>> This one is also pure code re-organisation, unless you've been able to 
>> spot a particular issue ?
> 
> Maybe commit cf9efce0ce31 ("powerpc: Account time using timebase rather 
> than PURR")
> 
> It removed snapshot_timebases() and I can't see anything to replace it.
> 

Yes. But this patch is dependent on Frederic's series.
backporting that is going to be difficult. So i am thinking to avoid putting Fixes tag.


> 
>>
>>>
>>>   arch/powerpc/kernel/time.c | 4 +++-
>>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
>>> index 3460d1a5a97c..11145c40183d 100644
>>> --- a/arch/powerpc/kernel/time.c
>>> +++ b/arch/powerpc/kernel/time.c
>>> @@ -377,7 +377,6 @@ void vtime_task_switch(struct task_struct *prev)
>>>       }
>>>   }
>>> -#ifdef CONFIG_NO_HZ_COMMON
>>>   /**
>>>    * vtime_reset - Fast forward vtime entry clocks
>>>    *
>>> @@ -394,6 +393,7 @@ void vtime_reset(void)
>>>   #endif
>>>   }
>>> +#ifdef CONFIG_NO_HZ_COMMON
>>>   /**
>>>    * vtime_dyntick_start - Inform vtime about entry to idle-dynticks
>>>    *
>>> @@ -933,6 +933,7 @@ static void __init set_decrementer_max(void)
>>>   static void __init init_decrementer_clockevent(void)
>>>   {
>>>       register_decrementer_clockevent(smp_processor_id());
>>> +    vtime_reset();
>>>   }
>>>   void secondary_cpu_time_init(void)
>>> @@ -948,6 +949,7 @@ void secondary_cpu_time_init(void)
>>>       /* FIME: Should make unrelated change to move snapshot_timebase
>>>        * call here ! */
>>>       register_decrementer_clockevent(smp_processor_id());
>>> +    vtime_reset();
>>>   }
>>>   /*
>>
> 

Sorry i should have put this earlier, But this applies on top of tip/timers/nohz
at 6199f9999a9b (origin/timers/nohz) sched/cputime: Handle dyntick-idle steal time correctly
(In case anyone tried applying on powerpc tree, it would fail)

Re: [PATCH] powerpc/vtime: Initialize starttime at boot for native accounting

[Christophe Leroy (CS GROUP)]

Hi Shrikanth,

Le 05/06/2026 à 05:03, Shrikanth Hegde a écrit :
> Hi Christophe. Thanks for taking a look and review.
> 
> On 6/4/26 8:42 PM, Christophe Leroy (CS GROUP) wrote:
>>
> 
>>>> Also, does this warrant Fixes tag? I found these two likely candidates.
>>>> Likely this issues exists since beginning.
>>>> c223c90386bc powerpc32: provide VIRT_CPU_ACCOUNTING
>>>
>>> You say system has 240 CPU so I suppose this is not ppc32. That 
>>> commit wsa not supposed to change anything for ppc64, did you 
>>> identify anything special in that commit related to ppc64 ?
> 
> Yes. this was ppc64.
> 
>>>
>>>> b38a181c11d0 powerpc/time: isolate scaled cputime accounting in 
>>>> dedicated functions.
>>>
>>> This one is also pure code re-organisation, unless you've been able 
>>> to spot a particular issue ?
>>
>> Maybe commit cf9efce0ce31 ("powerpc: Account time using timebase 
>> rather than PURR")
>>
>> It removed snapshot_timebases() and I can't see anything to replace it.
>>
> 
> Yes. But this patch is dependent on Frederic's series.
> backporting that is going to be difficult. So i am thinking to avoid 
> putting Fixes tag.

Even if automatic backport will fail, it shouldn't be difficult to 
perform a manual backport by just adding the missing vtime_reset().
So I would put the Fixes tag to make people award.

> 
> 
>>
>>>
>>>>
>>>>   arch/powerpc/kernel/time.c | 4 +++-
>>>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
>>>> index 3460d1a5a97c..11145c40183d 100644
>>>> --- a/arch/powerpc/kernel/time.c
>>>> +++ b/arch/powerpc/kernel/time.c
>>>> @@ -377,7 +377,6 @@ void vtime_task_switch(struct task_struct *prev)
>>>>       }
>>>>   }
>>>> -#ifdef CONFIG_NO_HZ_COMMON
>>>>   /**
>>>>    * vtime_reset - Fast forward vtime entry clocks
>>>>    *
>>>> @@ -394,6 +393,7 @@ void vtime_reset(void)
>>>>   #endif
>>>>   }
>>>> +#ifdef CONFIG_NO_HZ_COMMON
>>>>   /**
>>>>    * vtime_dyntick_start - Inform vtime about entry to idle-dynticks
>>>>    *
>>>> @@ -933,6 +933,7 @@ static void __init set_decrementer_max(void)
>>>>   static void __init init_decrementer_clockevent(void)
>>>>   {
>>>>       register_decrementer_clockevent(smp_processor_id());
>>>> +    vtime_reset();
>>>>   }
>>>>   void secondary_cpu_time_init(void)
>>>> @@ -948,6 +949,7 @@ void secondary_cpu_time_init(void)
>>>>       /* FIME: Should make unrelated change to move snapshot_timebase
>>>>        * call here ! */
>>>>       register_decrementer_clockevent(smp_processor_id());
>>>> +    vtime_reset();
>>>>   }
>>>>   /*
>>>
>>
> 
> Sorry i should have put this earlier, But this applies on top of tip/ 
> timers/nohz
> at 6199f9999a9b (origin/timers/nohz) sched/cputime: Handle dyntick-idle 
> steal time correctly
> (In case anyone tried applying on powerpc tree, it would fail)


Yep, I first looked vtime_reset() into linus tree, then found it in 
linux-next.

Christophe