I recently noticed that running the selftest/timers/posix_timers
test after a suspend/resume cycle in my VM environment was
hanging, because the ITIMER_VIRTUAL signal wasn't firing.
More specifically, it seemed like after a suspend, process utime
wasn't being updated unless the process was running on cpu 0.
I chased this down a bit, and it seems the problem is that
on resume, the paravirt_steal_clock() is reset to zero on all
cpus other then cpu0. This causes the rq->prev_steal_time
value to be set to a negative value, which mucks up the
rest of the time accounting.
I'm not sure if this is due to a bug in kvm or what.
I've not chased back how long this bug has been around,
but it seemed to crop up in at least 3.16 when I tried
it.
The following hack works around this, but I suspect
the steal-clock offset needs to be saved on suspend
and re-added on resume, or the prev_steal_time values
need to be reset, so that we can be robust in the
face of this sort of behavior.
Thoughts or other ideas?
thanks
-john
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Gleb Natapov <g...@kernel.org>
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Marcelo Tosatti <mtosa...@redhat.com>
---
kernel/sched/cputime.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 8394b1e..439d880 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -258,12 +258,17 @@ static __always_inline bool
steal_account_process_tick(void)
{
#ifdef CONFIG_PARAVIRT
if (static_key_false(¶virt_steal_enabled)) {
- u64 steal;
+ u64 steal, prev;
cputime_t steal_ct;
steal = paravirt_steal_clock(smp_processor_id());
- steal -= this_rq()->prev_steal_time;
-
+ prev = this_rq()->prev_steal_time;
+ if (steal >= prev)
+ steal -= prev;
+ else {
+ printk("WARNING: %lld - %lld is negative!!\n", steal,
prev);
+ this_rq()->prev_steal_time = steal;
+ }
/*
* cputime_t may be less precise than nsecs (eg: if it's
* based on jiffies). Lets cast the result to cputime
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
