Patch "sched/cputime: Fix steal time accounting vs. CPU hotplug" has been added to the 3.14-stable tree
Subsystems (2)
This is a note to let you know that I've just added the patch titled
sched/cputime: Fix steal time accounting vs. CPU hotplug
to the 3.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
sched-cputime-fix-steal-time-accounting-vs.-cpu-hotplug.patch
and it can be found in the queue-3.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
e9532e69b8d1d1284e8ecf8d2586de34aec61244Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <[email protected]>
Date: Fri, 4 Mar 2016 15:59:42 +0100
Subject: sched/cputime: Fix steal time accounting vs. CPU hotplug
From: Thomas Gleixner <[email protected]>
commit e9532e69b8d1d1284e8ecf8d2586de34aec61244 upstream.
On CPU hotplug the steal time accounting can keep a stale rq->prev_steal_time value over CPU down and up. So after the CPU comes up again the delta calculation in steal_account_process_tick() wreckages itself due to the unsigned math:
u64 steal = paravirt_steal_clock(smp_processor_id()); steal -= this_rq()->prev_steal_time;
So if steal is smaller than rq->prev_steal_time we end up with an insane large value which then gets added to rq->prev_steal_time, resulting in a permanent wreckage of the accounting. As a consequence the per CPU stats in /proc/stat become stale.
Nice trick to tell the world how idle the system is (100%) while the CPU is 100% busy running tasks. Though we prefer realistic numbers.
None of the accounting values which use a previous value to account for fractions is reset at CPU hotplug time. update_rq_clock_task() has a sanity check for prev_irq_time and prev_steal_time_rq, but that sanity check solely deals with clock warps and limits the /proc/stat visible wreckage. The prev_time values are still wrong.
Solution is simple: Reset rq->prev_*_time when the CPU is plugged in again.
--- kernel/sched/core.c | 1 + kernel/sched/sched.h | 13 +++++++++++++ 2 files changed, 14 insertions(+)
kernel/sched/core.c +1 -0
@@ -5064,6 +5064,7 @@ migration_call(struct notifier_block *nfcase CPU_UP_PREPARE : rq->calc_load_update = calc_load_update; +account_reset_rq (rq);break ;case CPU_ONLINE :
kernel/sched/sched.h +13 -0
@@ -1563,3 +1563,16 @@ static inline u64 irq_time_read(int cpu) }#endif /* CONFIG_64BIT */ #endif /* CONFIG_IRQ_TIME_ACCOUNTING */ + +static inline void account_reset_rq (struct rq *rq) +{ +#ifdef CONFIG_IRQ_TIME_ACCOUNTING + rq->prev_irq_time =0 ; +#endif +#ifdef CONFIG_PARAVIRT + rq->prev_steal_time =0 ; +#endif +#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING + rq->prev_steal_time_rq =0 ; +#endif +}
Patches currently in stable-queue which might be from [email protected] are
queue-3.14/bitops-do-not-default-to-__clear_bit-for-__clear_bit_unlock.patch queue-3.14/sched-cputime-fix-steal-time-accounting-vs.-cpu-hotplug.patch queue-3.14/x86-iopl-fix-iopl-capability-check-on-xen-pv.patch queue-3.14/x86-apic-fix-suspicious-rcu-usage-in-smp_trace_call_function_interrupt.patch