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) <[email protected]>
Signed-off-by: Shrikanth Hegde <[email protected]>
Reviewed-by: Christophe Leroy (CS GROUP) <[email protected]>
---
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();
}
/*
