s.
>
> Pull the check up to those functions, by making them simple
> wrappers around the user_enter and user_exit inline functions.
>
> Cc: Andy Lutomirski <l...@kernel.org>
> Cc: Frederic Weisbecker <fweis...@gmail.com>
> Cc: Rik van Riel <r...@redhat.com&
ext tracking functions are
> called by guest_enter and guest_exit.
>
> Split the body of context_tracking_entry and context_tracking_exit
> out to __-prefixed functions, and use them from KVM.
>
> Rik van Riel has measured this to speed up a tight vmentry/vmexit
> loop by abou
functions are
called by guest_enter and guest_exit.
Split the body of context_tracking_entry and context_tracking_exit
out to __-prefixed functions, and use them from KVM.
Rik van Riel has measured this to speed up a tight vmentry/vmexit
loop by about 2%.
Cc: Frederic Weisbecker fweis
On 04/28/2015 07:36 AM, Paolo Bonzini wrote:
All calls to context_tracking_enter and context_tracking_exit
are already checking context_tracking_is_enabled, except the
context_tracking_user_enter and context_tracking_user_exit
functions left in for the benefit of assembly calls.
Pull the
the check up to those functions, by making them simple
wrappers around the user_enter and user_exit inline functions.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Rik van Riel r...@redhat.com
--
All rights reversed
--
To unsubscribe from this list: send the line unsubscribe kvm
.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Acked-by: Rik van Riel r...@redhat.com
--
All rights reversed
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
the x86 task switch policy, which seems to work.
Signed-off-by: Rik van Riel r...@redhat.com
---
I still hope to put the larger FPU changes in at some point, but with
all the current changes to the FPU code I am somewhat uncomfortable
causing even more churn. After 4.1 I may send in the changes to defer
On 04/23/2015 06:57 PM, Wanpeng Li wrote:
Cc Rik, who is doing the similar work. :)
Hi Liang,
I posted this patch earlier, which should have the same effect as
your patch on more modern systems, while not loading the FPU context
for guests that barely use it on older systems:
On 04/09/2015 10:13 AM, Peter Zijlstra wrote:
On Thu, Apr 09, 2015 at 09:16:24AM -0400, Rik van Riel wrote:
On 04/09/2015 03:01 AM, Peter Zijlstra wrote:
On Wed, Apr 08, 2015 at 02:32:19PM -0400, Waiman Long wrote:
For a virtual guest with the qspinlock patch, a simple unfair byte lock
On 04/09/2015 03:01 AM, Peter Zijlstra wrote:
On Wed, Apr 08, 2015 at 02:32:19PM -0400, Waiman Long wrote:
For a virtual guest with the qspinlock patch, a simple unfair byte lock
will be used if PV spinlock is not configured in or the hypervisor
isn't either KVM or Xen. The byte lock works
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/12/2015 12:00 PM, Frederic Weisbecker wrote:
On Thu, Feb 12, 2015 at 10:47:10AM -0500, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 02/12/2015 10:42 AM, Frederic Weisbecker wrote:
On Wed, Feb 11, 2015 at 02:43:19PM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/12/2015 10:42 AM, Frederic Weisbecker wrote:
On Wed, Feb 11, 2015 at 02:43:19PM -0500, Rik van Riel wrote:
If exception_enter happens when already in IN_KERNEL state, the
code still calls context_tracking_exit, which ends up
to
IN_KERNEL state if the current state is not already IN_KERNEL.
Signed-off-by: Rik van Riel r...@redhat.com
Reported-by: Luiz Capitulino lcapitul...@redhat.com
---
Frederic, you will want this bonus patch, too :)
Thanks to Luiz for finding this one. Whatever I was running did not
trigger
On 02/10/2015 10:28 AM, Frederic Weisbecker wrote:
On Tue, Feb 10, 2015 at 09:41:45AM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
These wrapper functions allow architecture code (eg. ARM) to keep
calling context_tracking_user_enter context_tracking_user_exit
the same
On 02/10/2015 02:59 PM, Andy Lutomirski wrote:
On 02/10/2015 06:41 AM, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
The host kernel is not doing anything while the CPU is executing
a KVM guest VCPU, so it can be marked as being in an extended
quiescent state, identical
wrote:
On Fri, Feb 06, 2015 at 10:53:34PM -0500, Rik van Riel
wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 02/06/2015 06:15 PM, Frederic Weisbecker wrote:
Just a few things then:
1) In this case rename context_tracking_user_enter/exit()
to context_tracking_enter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/09/2015 08:15 PM, Will Deacon wrote:
Hi Rik,
On Mon, Feb 09, 2015 at 04:04:38PM +, r...@redhat.com wrote:
Apologies to Catalin and Will for not fixing up ARM. I am not
familiar with ARM assembly, and not sure how to pass a constant
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/09/2015 10:01 PM, Paul E. McKenney wrote:
On Tue, Feb 10, 2015 at 02:44:17AM +0100, Frederic Weisbecker
wrote:
On Mon, Feb 09, 2015 at 08:22:59PM -0500, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 02/09/2015 08:15
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/09/2015 12:05 PM, Paolo Bonzini wrote:
On 09/02/2015 17:04, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
Export context_tracking_user_enter/exit so it can be used by
KVM.
Wrong function name in the commit message
-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Rik van Riel r...@redhat.com
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJU2UOmAAoJEM553pKExN6DLKoIAJhuuGhD46k4Xyai8JdtTGPr
osSYKVjIn9PYCYDjR9NQuUfji1i5JXluFMDHLREnKnTQlzvC9+pKIfyxEObgI3ni
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/07/2015 03:30 AM, Frederic Weisbecker wrote:
I prefer a new series too. Now whether you or me take the patches,
I don't mind either way :-)
I'll make it, no problem.
Also I wonder how this feature is going to be enabled. Will it be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 01:23 PM, Frederic Weisbecker wrote:
On Fri, Feb 06, 2015 at 01:20:21PM -0500, Rik van Riel wrote: On
02/06/2015 12:22 PM, Frederic Weisbecker wrote:
On Thu, Feb 05, 2015 at 03:23:48PM -0500, r...@redhat.com
wrote:
From: Rik van
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 06:15 PM, Frederic Weisbecker wrote:
Just a few things then:
1) In this case rename context_tracking_user_enter/exit() to
context_tracking_enter() and context_tracking_exit(), since it's
not anymore about user only but about any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 08:46 AM, Frederic Weisbecker wrote:
On Thu, Feb 05, 2015 at 03:23:47PM -0500, r...@redhat.com wrote:
When running a KVM guest on a system with NOHZ_FULL enabled
I just need to clarify the motivation first, does the above
situation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/06/2015 12:22 PM, Frederic Weisbecker wrote:
On Thu, Feb 05, 2015 at 03:23:48PM -0500, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
Add the expected ctx_state as a parameter to
context_tracking_user_enter
On 02/05/2015 01:56 PM, Paul E. McKenney wrote:
The real danger is doing neither.
On tick_nohz_full_cpu() CPUs, the exit-to-userspace code should invoke
rcu_user_enter(), which sets some per-CPU state telling RCU to ignore
that CPU, since it cannot possibly do host RCU read-side critical
On 02/05/2015 02:20 PM, Paolo Bonzini wrote:
On 05/02/2015 19:55, Jan Kiszka 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.
Wouldn't it be better to
On 02/05/2015 11:44 AM, Christian Borntraeger wrote:
Am 05.02.2015 um 17:35 schrieb r...@redhat.com:
From: Rik van Riel r...@redhat.com
The host kernel is not doing anything while the CPU is executing
a KVM guest VCPU, so it can be marked as being in an extended
quiescent state, identical
a smaller average latency and
a smaller variance.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Acked-by: Rik van Riel r...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 02/05/2015 01:56 PM, Paul E. McKenney wrote:
On Thu, Feb 05, 2015 at 01:09:19PM -0500, Rik van Riel wrote:
On 02/05/2015 12:50 PM, Paul E. McKenney wrote:
On Thu, Feb 05, 2015 at 11:52:37AM -0500, Rik van Riel wrote:
On 02/05/2015 11:44 AM, Christian Borntraeger wrote:
Am 05.02.2015 um 17
On 02/05/2015 12:50 PM, Paul E. McKenney wrote:
On Thu, Feb 05, 2015 at 11:52:37AM -0500, Rik van Riel wrote:
On 02/05/2015 11:44 AM, Christian Borntraeger wrote:
Am 05.02.2015 um 17:35 schrieb r...@redhat.com:
From: Rik van Riel r...@redhat.com
The host kernel is not doing anything while
On 02/05/2015 02:27 PM, Paul E. McKenney wrote:
On Thu, Feb 05, 2015 at 02:02:35PM -0500, Rik van Riel wrote:
Looking at context_tracking.h, I see the
function context_tracking_cpu_is_enabled().
That looks like it should do the right thing
in this case.
Right you are -- that same check
latency in the
LAPIC path for a KVM guest.
This patch reduces the average latency in my tests from 14us to 11us.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Acked-by: Rik van Riel r...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
On 01/14/2015 12:12 PM, Marcelo Tosatti wrote:
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
Acked-by: Rik van Riel r...@redhat.com
On 12/11/2014 04:07 PM, Andy Lutomirski wrote:
On Thu, Dec 11, 2014 at 12:58 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Dec 11, 2014 at 12:48:36PM -0800, Andy Lutomirski wrote:
On 12/10/2014 07:07 PM, Marcelo Tosatti wrote:
On Thu, Dec 11, 2014 at 12:37:57AM +0100, Paolo Bonzini
On 12/10/2014 12:06 PM, Marcelo Tosatti wrote:
For the hrtimer which emulates the tscdeadline timer in the guest,
add an option to advance expiration, and busy spin on VM-entry waiting
for the actual expiration time to elapse.
This allows achieving low latencies in cyclictest (or any
On 12/10/2014 12:06 PM, Marcelo Tosatti wrote:
kvm_x86_ops-test_posted_interrupt() returns true/false depending
whether 'vector' is set.
Is that good? Bad? How does this patch address the issue?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On 12/10/2014 12:27 PM, Marcelo Tosatti wrote:
On Wed, Dec 10, 2014 at 12:10:04PM -0500, Rik van Riel wrote:
On 12/10/2014 12:06 PM, Marcelo Tosatti wrote:
kvm_x86_ops-test_posted_interrupt() returns true/false depending
whether 'vector' is set.
Is that good? Bad? How does this patch address
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/05/2014 03:17 AM, Thomas Lau wrote:
virsh cpu-models x86_64 | sort
...
Penryn SandyBridge Westmere
...
interesting that it doesn't have Ivy Bridge, any reason?
The reason would be that you are running an older version.
- --
All rights
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 thread is scheduled
This extra context switch introduces unnecessary
On 11/25/2014 01:57 PM, 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 thread is scheduled
This extra
mtosa...@redhat.com
Acked-by: Rik van Riel r...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
notifier, so a lot of code has been trivially
touched.
3. In the absence of shadow_accessed_mask (e.g. EPT A bit), we
emulate the access bit by blowing the spte. This requires proper
synchronizing with MMU notifier consumers, like every other removal
of spte's does.
Acked-by: Rik van Riel r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/21/2014 04:55 AM, Xuekun Hu wrote:
Hi, Rik
I saw your presentation at last year 2013 kvm submit.
(http://www.linux-kvm.org/wiki/images/2/27/Kvm-forum-2013-idle-latency.pdf).
You said there will have some patches later, but I didn't find
On 05/28/2014 08:16 AM, Raghavendra K T wrote:
This patch looks very promising.
TODO:
- we need an intelligent way to nullify the effect of batching for baremetal
(because extra cmpxchg is not required).
On (larger?) NUMA systems, the unfairness may be a nice performance
benefit, reducing
On 05/28/2014 06:19 PM, Linus Torvalds wrote:
If somebody has a P4 still, that's likely the worst case by far.
I'm sure cmpxchg isn't the only thing making P4 the worst case :)
--
All rights reversed
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On 04/22/2014 07:57 AM, Christian Borntraeger wrote:
On 22/04/14 12:55, Christian Borntraeger wrote:
While preparing/testing some KVM on s390 patches for the next merge window
(target is kvm/next which is based on 3.15-rc1) I faced a very severe
performance hickup on guest paging (all
On 02/18/2014 09:24 PM, David Rientjes wrote:
On Tue, 18 Feb 2014, r...@redhat.com wrote:
From: Rik van Riel r...@redhat.com
The NUMA scanning code can end up iterating over many gigabytes
of unpopulated memory, especially in the case of a freshly started
KVM guest with lots of memory
with.
Signed-off-by: Rik van Riel r...@redhat.com
Acked-by: David Rientjes rient...@google.com
---
mm/hugetlb.c | 2 ++
mm/mprotect.c | 15 ---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c0d930f..f0c5dfb 100644
--- a/mm/hugetlb.c
+++ b
in
11feeb498086a3a5907b8148bdf1786a9b18fc55. The cacheline was already
modified in order to set PG_tail so this won't affect the boot time of
large memory systems.
Reported-by: andy123 ajs124.ajs...@gmail.com
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
Acked-by: Rik van Riel r...@redhat.com
On 05/13/2013 11:16 AM, Michael S. Tsirkin wrote:
However, there's a big question mark: host specifies
inflate, guest says deflate, who wins?
If we're dealing with a NUMA guest, they could both win :)
The host could see reduced memory use of the guest in one
place, while the guest could see
On 05/13/2013 11:35 AM, Michael S. Tsirkin wrote:
On Mon, May 13, 2013 at 11:22:58AM -0400, Rik van Riel wrote:
I believe the Google patches still included some way for the
host to initiate balloon inflation on the guest side, because
the guest internal state alone is not enough to see when
On 05/12/2013 10:30 AM, Michael S. Tsirkin wrote:
On Thu, May 09, 2013 at 10:53:49AM -0400, Luiz Capitulino wrote:
Automatic ballooning consists of dynamically adjusting the guest's
balloon according to memory pressure in the host and in the guest.
This commit implements the guest side of
On 04/22/2013 07:51 AM, Peter Zijlstra wrote:
On Sun, 2013-04-21 at 17:12 -0400, Rik van Riel wrote:
If we always incremented the ticket number by 2 (instead of 1), then
we could use the lower bit of the ticket number as the spinlock.
ISTR that paravirt ticket locks already do that and use
On 04/22/2013 03:49 PM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 08:52 -0400, Rik van Riel wrote:
If the native spin_lock code has been called already at
that time, the native code would still need to be modified
to increment the ticket number by 2, so we end up with a
compatible value
On 04/22/2013 04:08 PM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 15:56 -0400, Rik van Riel wrote:
On 04/22/2013 03:49 PM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 08:52 -0400, Rik van Riel wrote:
If the native spin_lock code has been called already at
that time, the native code would
On 04/22/2013 04:46 PM, Jiannan Ouyang wrote:
It would still be very interesting to conduct more experiments to
compare these two, to see if the fairness enforced by pv_lock is
mandatory, and if preemptable-lock outperforms pv_lock in most cases,
and how do they work with PLE.
Given the
On 04/22/2013 04:48 PM, Peter Zijlstra wrote:
Hmm.. it looked like under light overcommit the paravirt ticket lock
still had some gain (~10%) and of course it brings the fairness thing
which is always good.
I can only imagine the mess unfair + vcpu preemption can bring to guest
tasks.
If you
On 04/22/2013 04:55 PM, Peter Zijlstra wrote:
On Mon, 2013-04-22 at 16:46 -0400, Jiannan Ouyang wrote:
- pv-preemptable-lock has much less performance variance compare to
pv_lock, because it adapts to preemption within VM,
other than using rescheduling that increase VM interference
I
On 04/22/2013 05:56 PM, Andi Kleen wrote:
Rik van Riel r...@redhat.com writes:
If we always incremented the ticket number by 2 (instead of 1), then
we could use the lower bit of the ticket number as the spinlock.
Spinning on a single bit is very inefficient, as you need to do
try lock
On 04/20/2013 06:12 PM, Jiannan Ouyang wrote:
Hello Everyone,
I recently came up with a spinlock algorithm that can adapt to
preemption, which you may be interested in. The intuition is to
downgrade a fair lock to an unfair lock automatically upon preemption,
and preserve the fairness
On 02/05/2013 04:49 PM, Michael Wolf wrote:
Expand the steal time msr to also contain the consigned time.
Signed-off-by: Michael Wolf m...@linux.vnet.ibm.com
---
arch/x86/include/asm/paravirt.h |4 ++--
arch/x86/include/asm/paravirt_types.h |2 +-
arch/x86/kernel/kvm.c
On 02/05/2013 04:49 PM, Michael Wolf wrote:
Change the paravirt calls that retrieve the steal-time information
from the host. Add to it getting the consigned value as well as
the steal time.
Signed-off-by: Michael Wolf m...@linux.vnet.ibm.com
diff --git
On 01/14/2013 01:24 PM, Andrew Clayton wrote:
On Mon, 14 Jan 2013 15:27:36 +0200, Gleb Natapov wrote:
On Sun, Jan 13, 2013 at 10:29:58PM +, Andrew Clayton wrote:
When running qemu-kvm under 64but Fedora 16 under current 3.8, it
just hangs at start up. Dong a ps -ef hangs the process at
On 10/16/2012 10:23 PM, Michael Wolf wrote:
In the case of where you have a system that is running in a
capped or overcommitted environment the user may see steal time
being reported in accounting tools such as top or vmstat. This can
cause confusion for the end user.
How do s390 and Power
...@prisktech.co.nz
Acked-by: Rik van Riel r...@redhat.com
--
All rights reversed
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/21/2012 08:00 AM, Raghavendra K T wrote:
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
When total number of VCPUs of system is less than or equal to physical CPUs,
PLE exits become costly since each VCPU can have dedicated PCPU, and
trying to find a target VCPU to yield_to just
when we have large
number of small guests), it is better to yield.
Reviewed-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Acked-by: Rik van Riel r...@redhat.com
--
All rights reversed
--
To unsubscribe from this list: send
On 09/21/2012 06:46 AM, Mel Gorman wrote:
Hi Andrew,
Richard Davies and Shaohua Li have both reported lock contention
problems in compaction on the zone and LRU locks as well as
significant amounts of time being spent in compaction. This series
aims to reduce lock contention and scanning rates
On 09/21/2012 09:46 AM, Takuya Yoshikawa wrote:
On Fri, 21 Sep 2012 17:30:20 +0530
Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote:
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
When PLE handler fails to find a better candidate to yield_to, it
goes back and does spin again.
the cached
information? If it's ignored too often, the scanning rates will still
be excessive. If the information is too stale then allocations will fail
that might have otherwise succeeded. In this patch
Big hammer, but I guess it is effective...
Acked-by: Rik van Riel r...@redhat.com
, it makes your next patches easier...
Acked-by: Rik van Riel r...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cycle through more
slowly can continue, even when this particular
zone is experiencing problems, so I guess this
is desired behaviour...
Acked-by: Rik van Riel r...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
there are no free pages in the pageblock then the lock will not be
acquired at all which reduces contention on zone-lock.
Signed-off-by: Mel Gorman mgor...@suse.de
Acked-by: Rik van Riel r...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord
then the LRU lock will not be acquired at all
which reduces contention on zone-lru_lock.
Signed-off-by: Mel Gorman mgor...@suse.de
Acked-by: Rik van Riel r...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
...@suse.de
Acked-by: Rik van Riel r...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/15/2012 11:55 AM, Richard Davies wrote:
Hi Rik, Mel and Shaohua,
Thank you for your latest patches. I attach my latest perf report for a slow
boot with all of these applied.
Mel asked for timings of the slow boots. It's very hard to give anything
useful here! A normal boot would be a
-compact_cached_free_pfn is never advanced until
the compaction run wraps around the start of the zone.
This merely moved the starting point for the quadratic behaviour
further into the zone, but the behaviour has still been observed.
It looks like another fix is required.
Signed-off-by: Rik van
do not suffer quadratic
behaviour any more.
Signed-off-by: Rik van Riel r...@redhat.com
Reported-by: Richard Davies rich...@daviesmail.org
diff --git a/mm/compaction.c b/mm/compaction.c
index 771775d..0656759 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -431,6 +431,24 @@ static bool
to less
efficient compaction when one thread has wrapped around to the
end of the zone, and another simultaneous compactor has not done
so yet. However, it should ensure that we do not suffer quadratic
behaviour any more.
Signed-off-by: Rik van Riel r...@redhat.com
Reported-by: Richard Davies rich
On 09/10/2012 01:37 PM, Mike Waychison wrote:
On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin m...@redhat.com wrote:
Also can you pls answer Avi's question?
How is overcommit managed?
Overcommit in our deployments is managed using memory cgroups on the
host. This allows us to have very
On 09/10/2012 04:19 PM, Peter Zijlstra wrote:
On Mon, 2012-09-10 at 15:12 -0500, Andrew Theurer wrote:
+ /*
+* if the target task is not running, then only yield if the
+* current task is in guest mode
+*/
+ if (!(p_rq-curr-flags PF_VCPU))
+
On 09/02/2012 06:12 AM, Gleb Natapov wrote:
On Thu, Aug 30, 2012 at 12:51:01AM +0530, Raghavendra K T wrote:
The idea of starting from next vcpu (source of yield_to + 1) seem to work
well for overcomitted guest rather than using last boosted vcpu. We can also
remove per VM variable with
On 08/25/2012 01:45 PM, Richard Davies wrote:
Are you talking about these patches?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c67fe3752abe6ab47639e2f9b836900c3dc3da84
http://marc.info/?l=linux-mmm=134521289221259
If so, I believe those are in 3.6.0-rc3, so I
On 08/22/2012 10:41 AM, Richard Davies wrote:
Avi Kivity wrote:
Richard Davies wrote:
I can trigger the slow boots without KSM and they have the same profile,
with _raw_spin_lock_irqsave and isolate_freepages_block at the top.
I reduced to 3x 20GB 8-core VMs on a 128GB host (rather than 3x
Thanks Marcelo for the review. Avi, Rik, Christian, please let me know
if this series looks good now.
The series looks good to me.
Reviewed-by: Rik van Riel r...@redhat.com
--
All rights reversed
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord
On 07/16/2012 06:07 AM, Avi Kivity wrote:
+{
+ bool eligible;
+
+ eligible = !vcpu-ple.cpu_relax_intercepted ||
+ (vcpu-ple.cpu_relax_intercepted
+vcpu-ple.dy_eligible);
+
+ if (vcpu-ple.cpu_relax_intercepted)
+
...@linux.vnet.ibm.com
Reviewed-by: Rik van Riel r...@redhat.com
--
All rights reversed
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/09/2012 02:20 AM, Raghavendra K T wrote:
Currently Pause Looop Exit (PLE) handler is doing directed yield to a
random VCPU on PL exit. Though we already have filtering while choosing
the candidate to yield_to, we can do better.
Problem is, for large vcpu guests, we have more probability
On 07/09/2012 02:20 AM, Raghavendra K T wrote:
+bool kvm_arch_vcpu_check_and_update_eligible(struct kvm_vcpu *vcpu)
+{
+ bool eligible;
+
+ eligible = !vcpu-arch.plo.pause_loop_exited ||
+ (vcpu-arch.plo.pause_loop_exited
+
On 07/09/2012 02:20 AM, Raghavendra K T wrote:
@@ -484,6 +484,13 @@ struct kvm_vcpu_arch {
u64 length;
u64 status;
} osvw;
+
+ /* Pause loop exit optimization */
+ struct {
+ bool pause_loop_exited;
+ bool
On 06/28/2012 06:55 PM, Vinod, Chegu wrote:
Hello,
I am just catching up on this email thread...
Perhaps one of you may be able to help answer this query.. preferably along
with some data. [BTW, I do understand the basic intent behind PLE in a typical
[sweet spot] use case where there is
On 06/26/2012 04:32 PM, Frank Swiderski wrote:
This implementation of a virtio balloon driver uses the page cache to
store pages that have been released to the host. The communication
(outside of target counts) is one way--the guest notifies the host when
it adds a page to the page cache,
On 06/26/2012 05:31 PM, Frank Swiderski wrote:
On Tue, Jun 26, 2012 at 1:40 PM, Rik van Rielr...@redhat.com wrote:
The code looks good to me, my only worry is the
code duplication. We now have 5 balloon drivers,
for 4 hypervisors, all implementing everything
from scratch...
Do you have any
On 06/20/2012 04:12 PM, Raghavendra K T wrote:
On 06/20/2012 02:21 AM, Rik van Riel wrote:
Please let me know how it goes.
Yes, have got result today, too tired to summarize. got better
performance result too. will come back again tomorrow morning.
have to post, randomized start point patch
and
may end up with all VCPUs pouncing on vcpu 0. With a large enough
guest, this can result in enormous runqueue lock contention, which
can prevent vcpu0 from running, leading to a livelock.
Changing to = makes sure we properly handle that case.
Signed-off-by: Rik van Riel r...@redhat.com
On 04/23/2012 12:40 PM, Ying Han wrote:
Avi, does this patch help the case as you mentioned above, where kvm
module is loaded but no virtual machines are present ? Why we have to
walk the empty while holding the spinlock?
It might help marginally, but rather than defending
the patch, it might
On 04/20/2012 06:11 PM, Andrew Morton wrote:
On Fri, 13 Apr 2012 15:38:41 -0700
Ying Hanying...@google.com wrote:
The mmu_shrink() is heavy by itself by iterating all kvms and holding
the kvm_lock. spotted the code w/ Rik during LSF, and it turns out we
don't need to call the shrinker if
On 04/11/2012 01:21 PM, Chegu Vinod wrote:
Hello,
While running an AIM7 (workfile.high_systime) in a single 40-way (or a single
60-way KVM guest) I noticed pretty bad performance when the guest was booted
with 3.3.1 kernel when compared to the same guest booted with 2.6.32-220
(RHEL6.2)
...@infradead.org
CC: Avi Kivitya...@redhat.com
CC: Anthony Liguorialigu...@us.ibm.com
CC: Eric B Munsonemun...@mgebm.net
Acked-by: Rik van Riel r...@redhat.com
--
All rights reversed
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord
1 - 100 of 288 matches
Mail list logo
