On 09/04/2009 05:48 PM, Andrew Theurer wrote:
Still not idle=poll, it may shave off 0.2%.
Won't this affect SMT in a negative way? (OK, I am not running SMT now,
but eventually we will be) A long time ago, we tested P4's with HT, and
a polling idle in one thread always negatively
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Vadim Rozenfeld
Sent: Saturday, September 05, 2009 2:35 PM
To: Brian Jackson
Cc: Andrew Theurer; kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: Use thread debug register storage
On 09/04/2009 08:04 PM, Brian Jackson wrote:
On Friday 04 September 2009 11:08:51 am Andrew Theurer wrote:
Brian Jackson wrote:
On Friday 04 September 2009 09:48:17 am Andrew Theurer wrote:
snip
Still not idle=poll, it may shave off 0.2%.
Won't this affect SMT
On Friday 04 September 2009 09:48:17 am Andrew Theurer wrote:
snip
Still not idle=poll, it may shave off 0.2%.
Won't this affect SMT in a negative way? (OK, I am not running SMT now,
but eventually we will be) A long time ago, we tested P4's with HT, and
a polling idle in one thread
On Tue, 2009-09-01 at 21:23 +0300, Avi Kivity wrote:
On 09/01/2009 09:12 PM, Andrew Theurer wrote:
Here's a run from branch debugreg with thread debugreg storage +
conditionally reload dr6:
user nice system irq softirq guest idle iowait
5.79 0.009.28 0.08 1.00 20.81
Brian Jackson wrote:
On Friday 04 September 2009 09:48:17 am Andrew Theurer wrote:
snip
Still not idle=poll, it may shave off 0.2%.
Won't this affect SMT in a negative way? (OK, I am not running SMT now,
but eventually we will be) A long time ago, we tested P4's with HT, and
a polling idle in
On Friday 04 September 2009 11:08:51 am Andrew Theurer wrote:
Brian Jackson wrote:
On Friday 04 September 2009 09:48:17 am Andrew Theurer wrote:
snip
Still not idle=poll, it may shave off 0.2%.
Won't this affect SMT in a negative way? (OK, I am not running SMT now,
but eventually
Instead of saving the debug registers from the processor to a kvm data
structure, rely in the debug registers stored in the thread structure.
This allows us not to save dr6 and dr7.
Reduces lightweight vmexit cost by 350 cycles, or 11 percent.
Signed-off-by: Avi Kivity a...@redhat.com
---
On 09/01/2009 12:44 PM, Avi Kivity wrote:
Instead of saving the debug registers from the processor to a kvm data
structure, rely in the debug registers stored in the thread structure.
This allows us not to save dr6 and dr7.
Reduces lightweight vmexit cost by 350 cycles, or 11 percent.
Avi Kivity wrote:
Instead of saving the debug registers from the processor to a kvm data
structure, rely in the debug registers stored in the thread structure.
This allows us not to save dr6 and dr7.
Reduces lightweight vmexit cost by 350 cycles, or 11 percent.
Signed-off-by: Avi Kivity
Jan Kiszka wrote:
Avi Kivity wrote:
Instead of saving the debug registers from the processor to a kvm data
structure, rely in the debug registers stored in the thread structure.
This allows us not to save dr6 and dr7.
Reduces lightweight vmexit cost by 350 cycles, or 11 percent.
On 09/01/2009 01:42 PM, Jan Kiszka wrote:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 891234b..9e3acbd 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3627,14 +3627,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
kvm_guest_enter();
-
On 09/01/2009 02:16 PM, Avi Kivity wrote:
set_debugreg(0, 7);
set_debugreg(vcpu-arch.eff_db[0], 0);
set_debugreg(vcpu-arch.eff_db[1], 1);
@@ -3645,15 +3638,14 @@ static int vcpu_enter_guest(struct kvm_vcpu
*vcpu)
trace_kvm_entry(vcpu-vcpu_id);
On Tue, Sep 01, 2009 at 12:44:08PM +0300, Avi Kivity wrote:
Instead of saving the debug registers from the processor to a kvm data
structure, rely in the debug registers stored in the thread structure.
This allows us not to save dr6 and dr7.
Reduces lightweight vmexit cost by 350 cycles, or
Marcelo Tosatti wrote:
On Tue, Sep 01, 2009 at 12:44:08PM +0300, Avi Kivity wrote:
Instead of saving the debug registers from the processor to a kvm data
structure, rely in the debug registers stored in the thread structure.
This allows us not to save dr6 and dr7.
Reduces lightweight vmexit
On Tue, Sep 01, 2009 at 01:28:46PM +0200, Jan Kiszka wrote:
Marcelo Tosatti wrote:
On Tue, Sep 01, 2009 at 12:44:08PM +0300, Avi Kivity wrote:
Instead of saving the debug registers from the processor to a kvm data
structure, rely in the debug registers stored in the thread structure.
This
Jan Kiszka wrote:
Marcelo Tosatti wrote:
On Tue, Sep 01, 2009 at 12:44:08PM +0300, Avi Kivity wrote:
Instead of saving the debug registers from the processor to a kvm data
structure, rely in the debug registers stored in the thread structure.
This allows us not to save dr6 and dr7.
Reduces
On 09/01/2009 02:22 PM, Marcelo Tosatti wrote:
On Tue, Sep 01, 2009 at 12:44:08PM +0300, Avi Kivity wrote:
Instead of saving the debug registers from the processor to a kvm data
structure, rely in the debug registers stored in the thread structure.
This allows us not to save dr6 and dr7.
On 09/01/2009 02:32 PM, Marcelo Tosatti wrote:
Nope, kgdb writes directly to the debug registers.
I vaguely recall someone trying to push a debug register management
framework. Did it hit mainline in the meantime? I do not find any trace
on quick glance, at least not in kgdb.
A simple
On 09/01/2009 02:33 PM, Jan Kiszka wrote:
For the time being, falling back to conservative save/restore if kgdb is
configured in and kgdb_connected != 0 should allow us to apply this
optimization otherwise.
I prefer a real fix instead of spaghettiing the code this way (and in
the
Avi Kivity wrote:
On 09/01/2009 02:33 PM, Jan Kiszka wrote:
For the time being, falling back to conservative save/restore if kgdb is
configured in and kgdb_connected != 0 should allow us to apply this
optimization otherwise.
I prefer a real fix instead of spaghettiing the code this way
On 09/01/2009 02:45 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 09/01/2009 02:33 PM, Jan Kiszka wrote:
For the time being, falling back to conservative save/restore if kgdb is
configured in and kgdb_connected != 0 should allow us to apply this
optimization otherwise.
I
Avi Kivity wrote:
On 09/01/2009 02:45 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 09/01/2009 02:33 PM, Jan Kiszka wrote:
For the time being, falling back to conservative save/restore if kgdb is
configured in and kgdb_connected != 0 should allow us to apply this
optimization
On 09/01/2009 03:01 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 09/01/2009 02:45 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 09/01/2009 02:33 PM, Jan Kiszka wrote:
For the time being, falling back to conservative save/restore if kgdb is
configured in and
On 09/01/2009 03:02 PM, Avi Kivity wrote:
Then we need to resolve it right from the start, not in some distant
future. We already have everything we need available, we could just try
to refactor it to a nicer interface (something that encapsulates both
compile and runtime tests).
I'll look at
Avi Kivity wrote:
On 09/01/2009 01:42 PM, Jan Kiszka wrote:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 891234b..9e3acbd 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3627,14 +3627,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
kvm_guest_enter();
On 09/01/2009 04:31 PM, Jan Kiszka wrote:
The hardware will clear dr7 on exit.
Given this fact, I wonder why you want to reload host dr0..3 on
vcpu-arch.switch_db_regs. if (unlikely(test_thread_flag(TIF_DEBUG)))
should suffice then, right?
I think you're right. It would mean
On Tue, 2009-09-01 at 12:47 +0300, Avi Kivity wrote:
On 09/01/2009 12:44 PM, Avi Kivity wrote:
Instead of saving the debug registers from the processor to a kvm data
structure, rely in the debug registers stored in the thread structure.
This allows us not to save dr6 and dr7.
Reduces
On 09/01/2009 09:12 PM, Andrew Theurer wrote:
Here's a run from branch debugreg with thread debugreg storage +
conditionally reload dr6:
user nice system irq softirq guest idle iowait
5.79 0.009.28 0.08 1.00 20.81 58.784.26
total busy: 36.97
Previous run that had avoided
29 matches
Mail list logo
