On Sun, Feb 22, 2015 at 09:48:21PM +0530, Tapasweni Pathak wrote:
Enable disabled interrupt, on unsuccessful operation.
Found by Coccinelle.
Signed-off-by: Tapasweni Pathak tapaswenipat...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
---
arch/mips/kvm/tlb.c |1 +
1 file
On Fri, Feb 27, 2015 at 04:32:38PM +0100, Radim Krčmář wrote:
In commit b4eef9b36db4, we started to use hwapic_isr_update() != NULL
instead of kvm_apic_vid_enabled(vcpu-kvm). This didn't work because
SVM had it defined and apicv path in apic_{set,clear}_isr() does not
change apic-isr_count,
On Tue, Feb 17, 2015 at 06:44:19PM +0100, Sebastian Andrzej Siewior wrote:
> * Peter Zijlstra | 2015-01-21 16:07:16 [+0100]:
>
> >On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote:
> >> I'm actually wondering if we should just nuke the _interruptible()
> >> version of swait. As it
On Thu, Feb 26, 2015 at 08:08:15AM +, Wu, Feng wrote:
>
>
> > -Original Message-
> > From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> > Sent: Thursday, February 26, 2015 5:50 AM
> > To: Wu, Feng
> > Cc: t...@linutronix.de; mi...@redhat.com; h.
On Fri, Dec 12, 2014 at 11:14:58PM +0800, Feng Wu wrote:
> This patch updates the Posted-Interrupts Descriptor when vCPU
> is blocked.
>
> pre-block:
> - Add the vCPU to the blocked per-CPU list
> - Clear 'SN'
> - Set 'NV' to POSTED_INTR_WAKEUP_VECTOR
>
> post-block:
> - Remove the vCPU from the
On Thu, Feb 26, 2015 at 10:49:53AM +0200, Nadav Amit wrote:
> Marcello, Radim,
>
> As you know - I can run some tests on the patches and whether they comply
> with real hardware. Please let me know which version to test and I’ll try to
> do next week.
>
> Regards,
> Nadav
>From what i
On Tue, Feb 17, 2015 at 06:44:19PM +0100, Sebastian Andrzej Siewior wrote:
* Peter Zijlstra | 2015-01-21 16:07:16 [+0100]:
On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote:
I'm actually wondering if we should just nuke the _interruptible()
version of swait. As it should only
On Thu, Feb 26, 2015 at 08:08:15AM +, Wu, Feng wrote:
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Sent: Thursday, February 26, 2015 5:50 AM
To: Wu, Feng
Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
g...@kernel.org
On Thu, Feb 26, 2015 at 10:49:53AM +0200, Nadav Amit wrote:
Marcello, Radim,
As you know - I can run some tests on the patches and whether they comply
with real hardware. Please let me know which version to test and I’ll try to
do next week.
Regards,
Nadav
From what i understand Radim
On Fri, Dec 12, 2014 at 11:14:58PM +0800, Feng Wu wrote:
This patch updates the Posted-Interrupts Descriptor when vCPU
is blocked.
pre-block:
- Add the vCPU to the blocked per-CPU list
- Clear 'SN'
- Set 'NV' to POSTED_INTR_WAKEUP_VECTOR
post-block:
- Remove the vCPU from the per-CPU
Radim,
On Thu, Feb 12, 2015 at 07:41:30PM +0100, Radim Krčmář wrote:
> Each patch has a diff from v1, here is only a prologue on the mythical
> mixed xAPIC and x2APIC mode:
>
> There is one interesting alias in xAPIC and x2APIC ICR destination, the
> 0xff00, which is a broadcast in xAPIC and
On Fri, Feb 20, 2015 at 08:21:36AM -0500, Kevin Mulvey wrote:
> Better alignment of loop using tabs rather than spaces, this
> makes checkpatch.pl happier.
>
> Signed-off-by: Kevin Mulvey
> ---
> virt/kvm/kvm_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied both, thanks.
On Sat, Feb 21, 2015 at 12:21:16AM +0100, Borislav Petkov wrote:
> On Fri, Feb 20, 2015 at 04:02:10PM -0600, Joel Schopp wrote:
> > From: David Kaplan
> >
> > KVM has nice wrappers to access the register values, clean up a few places
> > that should use them but currently do not.
> >
> >
On Fri, Dec 12, 2014 at 11:14:58PM +0800, Feng Wu wrote:
> This patch updates the Posted-Interrupts Descriptor when vCPU
> is blocked.
>
> pre-block:
> - Add the vCPU to the blocked per-CPU list
> - Clear 'SN'
> - Set 'NV' to POSTED_INTR_WAKEUP_VECTOR
>
> post-block:
> - Remove the vCPU from the
On Fri, Dec 12, 2014 at 11:14:58PM +0800, Feng Wu wrote:
This patch updates the Posted-Interrupts Descriptor when vCPU
is blocked.
pre-block:
- Add the vCPU to the blocked per-CPU list
- Clear 'SN'
- Set 'NV' to POSTED_INTR_WAKEUP_VECTOR
post-block:
- Remove the vCPU from the per-CPU
On Sat, Feb 21, 2015 at 12:21:16AM +0100, Borislav Petkov wrote:
On Fri, Feb 20, 2015 at 04:02:10PM -0600, Joel Schopp wrote:
From: David Kaplan david.kap...@amd.com
KVM has nice wrappers to access the register values, clean up a few places
that should use them but currently do not.
On Fri, Feb 20, 2015 at 08:21:36AM -0500, Kevin Mulvey wrote:
Better alignment of loop using tabs rather than spaces, this
makes checkpatch.pl happier.
Signed-off-by: Kevin Mulvey kmul...@linux.com
---
virt/kvm/kvm_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Applied
Radim,
On Thu, Feb 12, 2015 at 07:41:30PM +0100, Radim Krčmář wrote:
Each patch has a diff from v1, here is only a prologue on the mythical
mixed xAPIC and x2APIC mode:
There is one interesting alias in xAPIC and x2APIC ICR destination, the
0xff00, which is a broadcast in xAPIC and
On Fri, Dec 12, 2014 at 11:14:57PM +0800, Feng Wu wrote:
> This patch updates the Posted-Interrupts Descriptor when vCPU
> is preempted.
>
> sched out:
> - Set 'SN' to suppress furture non-urgent interrupts posted for
> the vCPU.
What wakes the vcpu in the case of a non-urgent interrupt, then?
On Fri, Dec 12, 2014 at 11:14:55PM +0800, Feng Wu wrote:
> Currently, we use a global vector as the Posted-Interrupts
> Notification Event for all the vCPUs in the system. We need
> to introduce another global vector for VT-d Posted-Interrtups,
> which will be used to wakeup the sleep vCPU when an
On Fri, Dec 12, 2014 at 11:14:55PM +0800, Feng Wu wrote:
Currently, we use a global vector as the Posted-Interrupts
Notification Event for all the vCPUs in the system. We need
to introduce another global vector for VT-d Posted-Interrtups,
which will be used to wakeup the sleep vCPU when an
On Fri, Dec 12, 2014 at 11:14:57PM +0800, Feng Wu wrote:
This patch updates the Posted-Interrupts Descriptor when vCPU
is preempted.
sched out:
- Set 'SN' to suppress furture non-urgent interrupts posted for
the vCPU.
What wakes the vcpu in the case of a non-urgent interrupt, then?
I
On Sat, Feb 07, 2015 at 09:33:09PM +0100, Paolo Bonzini wrote:
> > Can remove another 300 cycles from do_div when programming LAPIC
> > tscdeadline timer.
>
> Do you mean using something like lib/reciprocal_div.c?
Yes.
> Good idea,
> though that's not latency, it's just being slow. :)
It
On Sat, Feb 07, 2015 at 09:33:09PM +0100, Paolo Bonzini wrote:
Can remove another 300 cycles from do_div when programming LAPIC
tscdeadline timer.
Do you mean using something like lib/reciprocal_div.c?
Yes.
Good idea,
though that's not latency, it's just being slow. :)
It adds to
On Fri, Feb 06, 2015 at 01:16:59PM +0100, Paolo Bonzini wrote:
> The newly-added tracepoint shows the following results on
> the tscdeadline_latency test:
>
> qemu-kvm-8387 [002] 6425.558974: kvm_vcpu_wakeup: poll time
> 10407 ns
> qemu-kvm-8387 [002] 6425.558984:
On Fri, Feb 06, 2015 at 01:16:59PM +0100, Paolo Bonzini wrote:
The newly-added tracepoint shows the following results on
the tscdeadline_latency test:
qemu-kvm-8387 [002] 6425.558974: kvm_vcpu_wakeup: poll time
10407 ns
qemu-kvm-8387 [002] 6425.558984:
On Thu, Feb 05, 2015 at 09:34:06PM -0200, Marcelo Tosatti wrote:
> On Thu, Feb 05, 2015 at 05:05:25PM +0100, Paolo Bonzini wrote:
> > This patch introduces a new module parameter for the KVM module; when it
> > is present, KVM attempts a bit of polling on every HLT before scheduling
On Thu, Feb 05, 2015 at 05:05:25PM +0100, Paolo Bonzini wrote:
> This patch introduces a new module parameter for the KVM module; when it
> is present, KVM attempts a bit of polling on every HLT before scheduling
> itself out via kvm_vcpu_block.
>
> This parameter helps a lot for latency-bound
On Thu, Feb 05, 2015 at 05:05:25PM +0100, Paolo Bonzini wrote:
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via kvm_vcpu_block.
This parameter helps a lot for latency-bound
On Thu, Feb 05, 2015 at 09:34:06PM -0200, Marcelo Tosatti wrote:
On Thu, Feb 05, 2015 at 05:05:25PM +0100, Paolo Bonzini wrote:
This patch introduces a new module parameter for the KVM module; when it
is present, KVM attempts a bit of polling on every HLT before scheduling
itself out via
Ping ?
On Wed, Jan 14, 2015 at 03:21:47PM -0200, Marcelo Tosatti wrote:
>
> Ping?
>
> On Tue, Dec 30, 2014 at 05:52:28PM -0200, Marcelo Tosatti wrote:
> >
> > Commit "timers: do not raise softirq unconditionally", allows for timer
> > wheel processi
Ping ?
On Wed, Jan 14, 2015 at 03:21:47PM -0200, Marcelo Tosatti wrote:
Ping?
On Tue, Dec 30, 2014 at 05:52:28PM -0200, Marcelo Tosatti wrote:
Commit timers: do not raise softirq unconditionally, allows for timer
wheel processing (__run_timers) to be delayed for long periods of time
context.
cyclictest command line:
# cyclictest -m -n -q -p99 -l 100 -h60 -D 1m
This patch reduces the average latency in my tests from 14us to 11us.
Signed-off-by: Marcelo Tosatti
---
arch/arm/kvm/arm.c |4 ++--
arch/arm/kvm/psci.c |4 ++--
arch/mips
Since lapic timer handler only wakes up a simple waitqueue,
it can be executed from hardirq context.
Also handle the case where hrtimer_start_expires fails due to -ETIME,
by injecting the interrupt to the guest immediately.
Reduces average cyclictest latency by 3us.
Signed-off-by: Marcelo
Against v3.14-rt branch of
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
The problem:
On -RT, an emulated LAPIC timer instance has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra
Since lapic timer handler only wakes up a simple waitqueue,
it can be executed from hardirq context.
Also handle the case where hrtimer_start_expires fails due to -ETIME,
by injecting the interrupt to the guest immediately.
Reduces average cyclictest latency by 3us.
Signed-off-by: Marcelo
Against v3.14-rt branch of
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
The problem:
On -RT, an emulated LAPIC timer instance has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra
context.
cyclictest command line:
# cyclictest -m -n -q -p99 -l 100 -h60 -D 1m
This patch reduces the average latency in my tests from 14us to 11us.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
arch/arm/kvm/arm.c |4 ++--
arch/arm/kvm/psci.c
On Fri, Jan 16, 2015 at 11:48:46AM -0500, Steven Rostedt wrote:
> > @@ -971,8 +971,8 @@
> > kvm_mips_callbacks->queue_timer_int(vcpu);
> >
> > vcpu->arch.wait = 0;
> > - if (waitqueue_active(>wq)) {
> > - wake_up_interruptible(>wq);
> > + if (swaitqueue_active(>wq)) {
> > +
On Fri, Jan 16, 2015 at 11:48:46AM -0500, Steven Rostedt wrote:
@@ -971,8 +971,8 @@
kvm_mips_callbacks-queue_timer_int(vcpu);
vcpu-arch.wait = 0;
- if (waitqueue_active(vcpu-wq)) {
- wake_up_interruptible(vcpu-wq);
+ if (swaitqueue_active(vcpu-wq)) {
+
Ping?
On Tue, Dec 30, 2014 at 05:52:28PM -0200, Marcelo Tosatti wrote:
>
> Commit "timers: do not raise softirq unconditionally", allows for timer
> wheel processing (__run_timers) to be delayed for long periods of time.
>
> The effect is that
>
> loops
Against v3.14-rt branch of
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
The problem:
On -RT, an emulated LAPIC timer instance has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra
context.
cyclictest command line:
# cyclictest -m -n -q -p99 -l 100 -h60 -D 1m
This patch reduces the average latency in my tests from 14us to 11us.
Signed-off-by: Marcelo Tosatti
---
arch/arm/kvm/arm.c |4 ++--
arch/arm/kvm/psci.c |4 ++--
arch/mips
Since lapic timer handler only wakes up a simple waitqueue,
it can be executed from hardirq context.
Reduces average cyclictest latency by 3us.
Signed-off-by: Marcelo Tosatti
---
arch/x86/kvm/lapic.c | 42 +++---
1 file changed, 39 insertions(+), 3
Against v3.14-rt branch of
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
The problem:
On -RT, an emulated LAPIC timer instance has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra
Since lapic timer handler only wakes up a simple waitqueue,
it can be executed from hardirq context.
Reduces average cyclictest latency by 3us.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
arch/x86/kvm/lapic.c | 42 +++---
1 file changed, 39
context.
cyclictest command line:
# cyclictest -m -n -q -p99 -l 100 -h60 -D 1m
This patch reduces the average latency in my tests from 14us to 11us.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
arch/arm/kvm/arm.c |4 ++--
arch/arm/kvm/psci.c
Ping?
On Tue, Dec 30, 2014 at 05:52:28PM -0200, Marcelo Tosatti wrote:
Commit timers: do not raise softirq unconditionally, allows for timer
wheel processing (__run_timers) to be delayed for long periods of time.
The effect is that
loops = jiffies - base-timer_jiffies
Can grow
On Tue, Jan 06, 2015 at 11:49:09AM -0800, Andy Lutomirski wrote:
> On Tue, Jan 6, 2015 at 10:45 AM, Marcelo Tosatti wrote:
> > On Tue, Jan 06, 2015 at 10:26:22AM -0800, Andy Lutomirski wrote:
> >> On Tue, Jan 6, 2015 at 10:13 AM, Marcelo Tosatti
> >> wrote:
> >
On Tue, Jan 06, 2015 at 11:49:09AM -0800, Andy Lutomirski wrote:
On Tue, Jan 6, 2015 at 10:45 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Jan 06, 2015 at 10:26:22AM -0800, Andy Lutomirski wrote:
On Tue, Jan 6, 2015 at 10:13 AM, Marcelo Tosatti mtosa...@redhat.com
wrote
On Tue, Jan 06, 2015 at 11:18:21PM -0800, Andy Lutomirski wrote:
> On Tue, Jan 6, 2015 at 9:38 PM, Paolo Bonzini wrote:
> >
> >
> > On 06/01/2015 17:56, Andy Lutomirski wrote:
> >> Still no good. We can migrate a bunch of times so we see the same CPU
> >> all three times
> >
> > There are no
On Tue, Jan 06, 2015 at 11:18:21PM -0800, Andy Lutomirski wrote:
On Tue, Jan 6, 2015 at 9:38 PM, Paolo Bonzini pbonz...@redhat.com wrote:
On 06/01/2015 17:56, Andy Lutomirski wrote:
Still no good. We can migrate a bunch of times so we see the same CPU
all three times
There are no
On Tue, Jan 06, 2015 at 11:49:09AM -0800, Andy Lutomirski wrote:
> > What is the point with the new flags bit though?
>
> To try to work around the problem on old hosts. I'm not at all
> convinced that this is worthwhile or that it helps, though.
Don't think so. Just fix the host bug.
> >>
On Tue, Jan 06, 2015 at 10:26:22AM -0800, Andy Lutomirski wrote:
> On Tue, Jan 6, 2015 at 10:13 AM, Marcelo Tosatti wrote:
> > On Tue, Jan 06, 2015 at 08:56:40AM -0800, Andy Lutomirski wrote:
> >> On Jan 6, 2015 4:01 AM, "Paolo Bonzini" wrote:
> >> >
On Tue, Jan 06, 2015 at 08:56:40AM -0800, Andy Lutomirski wrote:
> On Jan 6, 2015 4:01 AM, "Paolo Bonzini" wrote:
> >
> >
> >
> > On 06/01/2015 09:42, Paolo Bonzini wrote:
> > > > > Still confused. So we can freeze all vCPUs in the host, then update
> > > > > pvti 1, then resume vCPU 1, then
On Tue, Jan 06, 2015 at 11:49:09AM -0800, Andy Lutomirski wrote:
What is the point with the new flags bit though?
To try to work around the problem on old hosts. I'm not at all
convinced that this is worthwhile or that it helps, though.
Don't think so. Just fix the host bug.
Also, if
On Tue, Jan 06, 2015 at 10:26:22AM -0800, Andy Lutomirski wrote:
On Tue, Jan 6, 2015 at 10:13 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Jan 06, 2015 at 08:56:40AM -0800, Andy Lutomirski wrote:
On Jan 6, 2015 4:01 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 06/01
On Tue, Jan 06, 2015 at 08:56:40AM -0800, Andy Lutomirski wrote:
On Jan 6, 2015 4:01 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 06/01/2015 09:42, Paolo Bonzini wrote:
Still confused. So we can freeze all vCPUs in the host, then update
pvti 1, then resume vCPU 1, then
On Mon, Jan 05, 2015 at 02:38:46PM -0800, Andy Lutomirski wrote:
> On Mon, Jan 5, 2015 at 11:17 AM, Marcelo Tosatti wrote:
> > On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
> >> On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti
> >> wrote:
> >
On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
> On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti wrote:
> > On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
> >> The pvclock vdso code was too abstracted to understand easily and
> &g
On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
> The pvclock vdso code was too abstracted to understand easily and
> excessively paranoid. Simplify it for a huge speedup.
>
> This opens the door for additional simplifications, as the vdso no
> longer accesses the pvti for any
On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid
On Mon, Jan 05, 2015 at 02:38:46PM -0800, Andy Lutomirski wrote:
On Mon, Jan 5, 2015 at 11:17 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti mtosa...@redhat.com
wrote:
On Mon
On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu
milliseconds to execute.
Fix by creating an upper bound on the number of loops to be processed.
This allows a nohz=off kernel to achieve desired latencies.
Signed-off-by: Marcelo Tosatti
diff --git a/kernel/timer.c b/kernel/timer.c
index f59e18c..c128416 100644
--- a/kernel/timer.c
+++ b/k
to execute.
Fix by creating an upper bound on the number of loops to be processed.
This allows a nohz=off kernel to achieve desired latencies.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/kernel/timer.c b/kernel/timer.c
index f59e18c..c128416 100644
--- a/kernel/timer.c
+++ b/kernel
On Mon, Dec 22, 2014 at 11:34:30AM -0200, Marcelo Tosatti wrote:
> > It would be even nicer, though, if we could do much the same thing but
> > without worrying about which vcpu we're on.
> >
> > Thoughts? Am I missing some considerations here?
>
> Maybe we
On Sat, Dec 20, 2014 at 07:31:19PM -0800, Andy Lutomirski wrote:
> I'm looking at the vdso timing code, and I'm puzzled by the pvclock
> code. My motivation is comprehensibility, performance, and
> correctness.
>
> # for i in `seq 10`; do ./timing_test_64 10 vclock_gettime 0; done
> 1000
On Sat, Dec 20, 2014 at 07:31:19PM -0800, Andy Lutomirski wrote:
> I'm looking at the vdso timing code, and I'm puzzled by the pvclock
> code. My motivation is comprehensibility, performance, and
> correctness.
>
> # for i in `seq 10`; do ./timing_test_64 10 vclock_gettime 0; done
> 1000
On Sat, Dec 20, 2014 at 07:31:19PM -0800, Andy Lutomirski wrote:
I'm looking at the vdso timing code, and I'm puzzled by the pvclock
code. My motivation is comprehensibility, performance, and
correctness.
# for i in `seq 10`; do ./timing_test_64 10 vclock_gettime 0; done
1000 loops in
On Sat, Dec 20, 2014 at 07:31:19PM -0800, Andy Lutomirski wrote:
I'm looking at the vdso timing code, and I'm puzzled by the pvclock
code. My motivation is comprehensibility, performance, and
correctness.
# for i in `seq 10`; do ./timing_test_64 10 vclock_gettime 0; done
1000 loops in
On Mon, Dec 22, 2014 at 11:34:30AM -0200, Marcelo Tosatti wrote:
It would be even nicer, though, if we could do much the same thing but
without worrying about which vcpu we're on.
Thoughts? Am I missing some considerations here?
Maybe we can find another optimization opportunities
On Thu, Dec 04, 2014 at 02:53:26PM +0100, Paolo Bonzini wrote:
>
>
> On 25/11/2014 21:24, Thomas Gleixner wrote:
> > On Tue, 25 Nov 2014, Rik van Riel wrote:
> >> On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
> >>> Since lapic timer handler only wakes
On Thu, Dec 04, 2014 at 02:53:26PM +0100, Paolo Bonzini wrote:
On 25/11/2014 21:24, Thomas Gleixner wrote:
On Tue, 25 Nov 2014, Rik van Riel wrote:
On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
Since lapic timer handler only wakes up a simple waitqueue,
it can be executed from
On Tue, Nov 25, 2014 at 06:38:04PM +0100, Paolo Bonzini wrote:
>
>
> On 25/11/2014 18:21, Marcelo Tosatti wrote:
> > +
> > + if (r == HRTIMER_RESTART) {
> > + do {
> > + ret = hrtimer_start_expires(data, HRTIMER_MODE_ABS);
> >
On Tue, Nov 25, 2014 at 06:38:04PM +0100, Paolo Bonzini wrote:
On 25/11/2014 18:21, Marcelo Tosatti wrote:
+
+ if (r == HRTIMER_RESTART) {
+ do {
+ ret = hrtimer_start_expires(data, HRTIMER_MODE_ABS);
+ if (ret == -ETIME
On Tue, Nov 25, 2014 at 01:57:37PM -0500, Rik van Riel wrote:
> On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
> > The problem:
> >
> > On -RT, an emulated LAPIC timer instances has the following path:
> >
> > 1) hard interrupt
> > 2) ksoftirqd is schedule
context.
cyclictest command line:
# cyclictest -m -n -q -p99 -l 100 -h60 -D 1m
This patch reduces the average latency in my tests from 14us to 11us.
Signed-off-by: Marcelo Tosatti
---
arch/arm/kvm/arm.c |4 ++--
arch/arm/kvm/psci.c |4 ++--
arch/mips
Since lapic timer handler only wakes up a simple waitqueue,
it can be executed from hardirq context.
Reduces average cyclictest latency by 3us.
Signed-off-by: Marcelo Tosatti
---
arch/x86/kvm/lapic.c | 42 +++---
1 file changed, 39 insertions(+), 3
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context switch introduces unnecessary latency in the
LAPIC path for a KVM guest.
The solution:
Since lapic timer handler only wakes up a simple waitqueue,
it can be executed from hardirq context.
Reduces average cyclictest latency by 3us.
Signed-off-by: Marcelo Tosatti
---
arch/x86/kvm/lapic.c | 42 +++---
1 file changed, 39 insertions(+), 3
This allows waking up vcpu thread from hardirq context.
Signed-off-by: Marcelo Tosatti
---
arch/arm/kvm/arm.c |4 ++--
arch/arm/kvm/psci.c |4 ++--
arch/mips/kvm/kvm_mips.c|8
arch/powerpc/include/asm/kvm_host.h |4
Which allows waking up vcpu from hardirq context.
--
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/
Which allows waking up vcpu from hardirq context.
--
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/
Since lapic timer handler only wakes up a simple waitqueue,
it can be executed from hardirq context.
Reduces average cyclictest latency by 3us.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
arch/x86/kvm/lapic.c | 42 +++---
1 file changed, 39
This allows waking up vcpu thread from hardirq context.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
arch/arm/kvm/arm.c |4 ++--
arch/arm/kvm/psci.c |4 ++--
arch/mips/kvm/kvm_mips.c|8
arch/powerpc/include/asm
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context switch introduces unnecessary latency in the
LAPIC path for a KVM guest.
The solution:
Since lapic timer handler only wakes up a simple waitqueue,
it can be executed from hardirq context.
Reduces average cyclictest latency by 3us.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
arch/x86/kvm/lapic.c | 42 +++---
1 file changed, 39
context.
cyclictest command line:
# cyclictest -m -n -q -p99 -l 100 -h60 -D 1m
This patch reduces the average latency in my tests from 14us to 11us.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
arch/arm/kvm/arm.c |4 ++--
arch/arm/kvm/psci.c
On Tue, Nov 25, 2014 at 01:57:37PM -0500, Rik van Riel wrote:
On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu
On Wed, Nov 05, 2014 at 11:46:42AM -0800, David Matlack wrote:
> The new trace event records:
> * the id of vcpu being updated
> * the pvclock_vcpu_time_info struct being written to guest memory
>
> This is useful for debugging pvclock bugs, such as the bug fixed by
> "[PATCH] kvm: x86: Fix
On Wed, Nov 05, 2014 at 11:46:42AM -0800, David Matlack wrote:
The new trace event records:
* the id of vcpu being updated
* the pvclock_vcpu_time_info struct being written to guest memory
This is useful for debugging pvclock bugs, such as the bug fixed by
[PATCH] kvm: x86: Fix kvm
On Tue, Sep 30, 2014 at 02:05:09PM +0200, Paolo Bonzini wrote:
> Il 30/09/2014 09:59, Fengguang Wu ha scritto:
> > +--++++
> > | | 71056ae22d
On Tue, Sep 30, 2014 at 02:05:09PM +0200, Paolo Bonzini wrote:
Il 30/09/2014 09:59, Fengguang Wu ha scritto:
+--++++
| | 71056ae22d
|
On Mon, Sep 22, 2014 at 03:58:16PM -0700, David Matlack wrote:
> > Should not be executing vcpu ioctls without interrupt KVM_RUN in the
> > first place.
>
> This patch is trying to be nice to code that isn't aware it's
> probing kvm file descriptors. We saw long hangs with some generic
> process
On Mon, Sep 22, 2014 at 11:29:16PM +0200, Paolo Bonzini wrote:
> Il 22/09/2014 22:08, Marcelo Tosatti ha scritto:
> > > This patch does not change functionality, it just makes invalid ioctls
> > > fail faster.
> >
> > Should not be executing vcpu ioctls without i
On Fri, Sep 19, 2014 at 04:03:25PM -0700, David Matlack wrote:
> vcpu ioctls can hang the calling thread if issued while a vcpu is
> running.
There is a mutex per-vcpu, so thats expected, OK...
> If we know ioctl is going to be rejected as invalid anyway,
> we can fail before trying to take the
On Fri, Sep 19, 2014 at 04:03:25PM -0700, David Matlack wrote:
vcpu ioctls can hang the calling thread if issued while a vcpu is
running.
There is a mutex per-vcpu, so thats expected, OK...
If we know ioctl is going to be rejected as invalid anyway,
we can fail before trying to take the
On Mon, Sep 22, 2014 at 11:29:16PM +0200, Paolo Bonzini wrote:
Il 22/09/2014 22:08, Marcelo Tosatti ha scritto:
This patch does not change functionality, it just makes invalid ioctls
fail faster.
Should not be executing vcpu ioctls without interrupt KVM_RUN in the
first place
On Mon, Sep 22, 2014 at 03:58:16PM -0700, David Matlack wrote:
Should not be executing vcpu ioctls without interrupt KVM_RUN in the
first place.
This patch is trying to be nice to code that isn't aware it's
probing kvm file descriptors. We saw long hangs with some generic
process
701 - 800 of 2527 matches
Mail list logo
