Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1420694 > unrolled thread

[PATCH v6 1/3] KVM: fix steal clock warp during guest cpu hotplug

Started byWanpeng Li <kernellwp@gmail.com>
First post2016-06-13 12:40 +0200
Last post2016-06-14 13:30 +0200
Articles 5 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v6 1/3] KVM: fix steal clock warp during guest cpu hotplug Wanpeng Li <kernellwp@gmail.com> - 2016-06-13 12:40 +0200
    Re: [PATCH v6 1/3] KVM: fix steal clock warp during guest cpu hotplug Paolo Bonzini <pbonzini@redhat.com> - 2016-06-13 12:50 +0200
      Re: [PATCH v6 1/3] KVM: fix steal clock warp during guest cpu hotplug Peter Zijlstra <peterz@infradead.org> - 2016-06-13 13:30 +0200
      Re: [PATCH v6 1/3] KVM: fix steal clock warp during guest cpu hotplug Wanpeng Li <kernellwp@gmail.com> - 2016-06-13 13:40 +0200
    [tip:sched/core] KVM: Fix steal clock warp during guest CPU hotplug tip-bot for Wanpeng Li <tipbot@zytor.com> - 2016-06-14 13:30 +0200

#1420694 — [PATCH v6 1/3] KVM: fix steal clock warp during guest cpu hotplug

FromWanpeng Li <kernellwp@gmail.com>
Date2016-06-13 12:40 +0200
Subject[PATCH v6 1/3] KVM: fix steal clock warp during guest cpu hotplug
Message-ID<rJxrH-52s-21@gated-at.bofh.it>
From: Wanpeng Li <wanpeng.li@hotmail.com>

Sometimes, after CPU hotplug you can observe a spike in stolen time
(100%) followed by the CPU being marked as 100% idle when it's actually
busy with a CPU hog task.  The trace looks like the following:

cpuhp/1-12    [001] d.h1   167.461657: account_process_tick: steal = 1291385514, prev_steal_time = 0
cpuhp/1-12    [001] d.h1   167.461659: account_process_tick: steal_jiffies = 1291
<idle>-0     [001] d.h1   167.462663: account_process_tick: steal = 18732255, prev_steal_time = 1291000000
<idle>-0     [001] d.h1   167.462664: account_process_tick: steal_jiffies = 18446744072437

The sudden decrease of "steal" causes steal_jiffies to underflow.
The root cause is kvm_steal_time being reset to 0 after hot-plugging
back in a CPU.  Instead, the preexisting value can be used, which is
what the core scheduler code expects.

John Stultz also reported a similar issue after guest S3.

Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
---
 arch/x86/kernel/kvm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index eea2a6f..1ef5e48 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -301,8 +301,6 @@ static void kvm_register_steal_time(void)
 	if (!has_steal_clock)
 		return;
 
-	memset(st, 0, sizeof(*st));
-
 	wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | KVM_MSR_ENABLED));
 	pr_info("kvm-stealtime: cpu %d, msr %llx\n",
 		cpu, (unsigned long long) slow_virt_to_phys(st));
-- 
1.9.1

[toc] | [next] | [standalone]

#1420712

FromPaolo Bonzini <pbonzini@redhat.com>
Date2016-06-13 12:50 +0200
Message-ID<rJxBn-56h-21@gated-at.bofh.it>
In reply to#1420694

On 13/06/2016 12:32, Wanpeng Li wrote:
> From: Wanpeng Li <wanpeng.li@hotmail.com>
> 
> Sometimes, after CPU hotplug you can observe a spike in stolen time
> (100%) followed by the CPU being marked as 100% idle when it's actually
> busy with a CPU hog task.  The trace looks like the following:
> 
> cpuhp/1-12    [001] d.h1   167.461657: account_process_tick: steal = 1291385514, prev_steal_time = 0
> cpuhp/1-12    [001] d.h1   167.461659: account_process_tick: steal_jiffies = 1291
> <idle>-0     [001] d.h1   167.462663: account_process_tick: steal = 18732255, prev_steal_time = 1291000000
> <idle>-0     [001] d.h1   167.462664: account_process_tick: steal_jiffies = 18446744072437
> 
> The sudden decrease of "steal" causes steal_jiffies to underflow.
> The root cause is kvm_steal_time being reset to 0 after hot-plugging
> back in a CPU.  Instead, the preexisting value can be used, which is
> what the core scheduler code expects.
> 
> John Stultz also reported a similar issue after guest S3.
> 
> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Radim Krčmář <rkrcmar@redhat.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: John Stultz <john.stultz@linaro.org>
> Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
> ---
>  arch/x86/kernel/kvm.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index eea2a6f..1ef5e48 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -301,8 +301,6 @@ static void kvm_register_steal_time(void)
>  	if (!has_steal_clock)
>  		return;
>  
> -	memset(st, 0, sizeof(*st));
> -
>  	wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | KVM_MSR_ENABLED));
>  	pr_info("kvm-stealtime: cpu %d, msr %llx\n",
>  		cpu, (unsigned long long) slow_virt_to_phys(st));
> 

Because there's no cover letter, I guess I have to ack each patch
independently.

Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Also, there's really no relation between patches 1-2 and 3...

Paolo

[toc] | [prev] | [next] | [standalone]

#1420727

FromPeter Zijlstra <peterz@infradead.org>
Date2016-06-13 13:30 +0200
Message-ID<rJye5-5AU-1@gated-at.bofh.it>
In reply to#1420712
On Mon, Jun 13, 2016 at 12:44:46PM +0200, Paolo Bonzini wrote:
> Because there's no cover letter, I guess I have to ack each patch
> independently.
> 
> Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Thanks, I'll take the lot through the sched tree.

[toc] | [prev] | [next] | [standalone]

#1420734

FromWanpeng Li <kernellwp@gmail.com>
Date2016-06-13 13:40 +0200
Message-ID<rJynL-5Ep-1@gated-at.bofh.it>
In reply to#1420712
2016-06-13 18:44 GMT+08:00 Paolo Bonzini <pbonzini@redhat.com>:
>
>
> On 13/06/2016 12:32, Wanpeng Li wrote:
>> From: Wanpeng Li <wanpeng.li@hotmail.com>
>>
>> Sometimes, after CPU hotplug you can observe a spike in stolen time
>> (100%) followed by the CPU being marked as 100% idle when it's actually
>> busy with a CPU hog task.  The trace looks like the following:
>>
>> cpuhp/1-12    [001] d.h1   167.461657: account_process_tick: steal = 1291385514, prev_steal_time = 0
>> cpuhp/1-12    [001] d.h1   167.461659: account_process_tick: steal_jiffies = 1291
>> <idle>-0     [001] d.h1   167.462663: account_process_tick: steal = 18732255, prev_steal_time = 1291000000
>> <idle>-0     [001] d.h1   167.462664: account_process_tick: steal_jiffies = 18446744072437
>>
>> The sudden decrease of "steal" causes steal_jiffies to underflow.
>> The root cause is kvm_steal_time being reset to 0 after hot-plugging
>> back in a CPU.  Instead, the preexisting value can be used, which is
>> what the core scheduler code expects.
>>
>> John Stultz also reported a similar issue after guest S3.
>>
>> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: Radim Krčmář <rkrcmar@redhat.com>
>> Cc: Ingo Molnar <mingo@kernel.org>
>> Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
>> Cc: Rik van Riel <riel@redhat.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Frederic Weisbecker <fweisbec@gmail.com>
>> Cc: John Stultz <john.stultz@linaro.org>
>> Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
>> ---
>>  arch/x86/kernel/kvm.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
>> index eea2a6f..1ef5e48 100644
>> --- a/arch/x86/kernel/kvm.c
>> +++ b/arch/x86/kernel/kvm.c
>> @@ -301,8 +301,6 @@ static void kvm_register_steal_time(void)
>>       if (!has_steal_clock)
>>               return;
>>
>> -     memset(st, 0, sizeof(*st));
>> -
>>       wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | KVM_MSR_ENABLED));
>>       pr_info("kvm-stealtime: cpu %d, msr %llx\n",
>>               cpu, (unsigned long long) slow_virt_to_phys(st));
>>
>
> Because there's no cover letter, I guess I have to ack each patch
> independently.
>
> Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Thanks for your and Rik's review, actually there is a cover letter for
this version, it seems that it just send to ML and forgot to Cc
maintainers/reviewers.

Regards,
Wanpeng Li

[toc] | [prev] | [next] | [standalone]

#1421781 — [tip:sched/core] KVM: Fix steal clock warp during guest CPU hotplug

Fromtip-bot for Wanpeng Li <tipbot@zytor.com>
Date2016-06-14 13:30 +0200
Subject[tip:sched/core] KVM: Fix steal clock warp during guest CPU hotplug
Message-ID<rJUHD-49V-17@gated-at.bofh.it>
In reply to#1420694
Commit-ID:  2348140d58f4f4245e9635ea8f1a77e940a4d877
Gitweb:     http://git.kernel.org/tip/2348140d58f4f4245e9635ea8f1a77e940a4d877
Author:     Wanpeng Li <wanpeng.li@hotmail.com>
AuthorDate: Mon, 13 Jun 2016 18:32:44 +0800
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Tue, 14 Jun 2016 11:13:14 +0200

KVM: Fix steal clock warp during guest CPU hotplug

Sometimes, after CPU hotplug you can observe a spike in stolen time
(100%) followed by the CPU being marked as 100% idle when it's actually
busy with a CPU hog task.  The trace looks like the following:

 cpuhp/1-12    [001] d.h1   167.461657: account_process_tick: steal = 1291385514, prev_steal_time = 0
 cpuhp/1-12    [001] d.h1   167.461659: account_process_tick: steal_jiffies = 1291
  <idle>-0     [001] d.h1   167.462663: account_process_tick: steal = 18732255, prev_steal_time = 1291000000
  <idle>-0     [001] d.h1   167.462664: account_process_tick: steal_jiffies = 18446744072437

The sudden decrease of "steal" causes steal_jiffies to underflow.
The root cause is kvm_steal_time being reset to 0 after hot-plugging
back in a CPU.  Instead, the preexisting value can be used, which is
what the core scheduler code expects.

John Stultz also reported a similar issue after guest S3.

Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1465813966-3116-2-git-send-email-wanpeng.li@hotmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/kernel/kvm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index eea2a6f..1ef5e48 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -301,8 +301,6 @@ static void kvm_register_steal_time(void)
 	if (!has_steal_clock)
 		return;
 
-	memset(st, 0, sizeof(*st));
-
 	wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | KVM_MSR_ENABLED));
 	pr_info("kvm-stealtime: cpu %d, msr %llx\n",
 		cpu, (unsigned long long) slow_virt_to_phys(st));

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web