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
> Cc: Frederic Weisbecker
> Cc: Rik van Riel
> Cc: Paul McKenney
> Signed-off-by: Paolo Bonzini
Reviewed-by
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 a
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 about
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 t
s.
>
> Pull 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
Reviewed-by: Rik van Riel
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscri
Intel i7-3520M @ 2.90GHz.
>
> Signed-off-by: Marcelo Tosatti
Acked-by: Rik van Riel
--
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 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:
https://lkml.org/
x86 task switch policy, which seems to work.
Signed-off-by: Rik van Riel
---
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
loading of user
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 qspinlo
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 wor
-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:
>&g
-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, w
IN_KERNEL state if the current state is not already IN_KERNEL.
Signed-off-by: Rik van Riel
Reported-by: Luiz Capitulino
---
Frederic, you will want this "bonus" patch, too :)
Thanks to Luiz for finding this one. Whatever I was running did not
trigger this issue...
inc
From: Rik van Riel
Export context_tracking_user_enter/exit so it can be used by KVM.
Signed-off-by: Rik van Riel
---
kernel/context_tracking.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 0e4e318d5ea4..5bdf1a342ab3 100644
When running a KVM guest on a system with NOHZ_FULL enabled, and the
KVM guest running with idle=poll mode, we still get wakeups of the
rcuos/N threads.
This problem has already been solved for user space by telling the
RCU subsystem that the CPU is in an extended quiescent state while
running use
From: Rik van Riel
With code elsewhere doing something conditional on whether or not
context tracking is enabled, we want a stub function that tells us
context tracking is not enabled, when CONFIG_CONTEXT_TRACKING is
not set.
Signed-off-by: Rik van Riel
---
include/linux
From: Rik van Riel
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 to that used when running user space
code.
The only exception to that rule is when the host handles an
interrupt, which is
From: Rik van Riel
Split out the mechanism from context_tracking_user_enter and
context_tracking_user_exit into context_tracking_enter and
context_tracking_exit. Leave the old functions in order to avoid
breaking ARM, which calls these functions from assembler code,
and cannot easily use C enum
From: Rik van Riel
Only run vtime_user_enter, vtime_user_exit, and the user enter & exit
trace points when we are entering or exiting user state, respectively.
The KVM code in guest_enter and guest_exit already take care of calling
vtime_guest_enter and vtime_guest_exit, respectively.
The
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
>>
>> 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
>> quiesc
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
>>
>> These wrapper functions allow architecture code (eg. ARM) to keep
>> calling context_tracking_user_enter & context_tra
From: Rik van Riel
Export context_tracking_user_enter/exit so it can be used by KVM.
Signed-off-by: Rik van Riel
---
kernel/context_tracking.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 0e4e318d5ea4..5bdf1a342ab3 100644
From: Rik van Riel
Add the expected ctx_state as a parameter to context_tracking_enter and
context_tracking_exit, allowing the same functions to not just track
kernel <> user space switching, but also kernel <> guest transitions.
Signed-off-by: Rik van Riel
---
i
From: Rik van Riel
Only run vtime_user_enter, vtime_user_exit, and the user enter & exit
trace points when we are entering or exiting user state, respectively.
The KVM code in guest_enter and guest_exit already take care of calling
vtime_guest_enter and vtime_guest_exit, respectively.
The
When running a KVM guest on a system with NOHZ_FULL enabled, and the
KVM guest running with idle=poll mode, we still get wakeups of the
rcuos/N threads.
This problem has already been solved for user space by telling the
RCU subsystem that the CPU is in an extended quiescent state while
running use
From: Rik van Riel
These wrapper functions allow architecture code (eg. ARM) to keep
calling context_tracking_user_enter & context_tracking_user_exit
the same way it always has, without error prone tricks like duplicate
defines of argument values in assembly code.
Signed-off-by: Rik van
From: Rik van Riel
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 to that used when running user space
code.
The only exception to that rule is when the host handles an
interrupt, which is
From: Rik van Riel
With code elsewhere doing something conditional on whether or not
context tracking is enabled, we want a stub function that tells us
context tracking is not enabled, when CONFIG_CONTEXT_TRACKING is
not set.
Signed-off-by: Rik van Riel
---
include/linux
-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
-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 const
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Rik van Riel
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJU2UOmAAoJEM553pKExN6DLKoIAJhuuGhD46k4Xyai8JdtTGPr
osSYKVjIn9PYCYDjR9NQuUfji1i5JXluFMDHLREnKnTQlzvC9+pKIfyxEObgI3ni
8uYs5mealtFAv3u
-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
>>
>> Export context_tracking_user_enter/exit so it can be used by
>> KVM.
>
> Wrong funct
From: Rik van Riel
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 to that used when running user space
code.
The only exception to that rule is when the host handles an
interrupt, which is
When running a KVM guest on a system with NOHZ_FULL enabled, and the
KVM guest running with idle=poll mode, we still get wakeups of the
rcuos/N threads.
This problem has already been solved for user space by telling the
RCU subsystem that the CPU is in an extended quiescent state while
running use
From: Rik van Riel
Add the expected ctx_state as a parameter to context_tracking_user_enter
and context_tracking_user_exit, allowing the same functions to not just
track kernel <> user space switching, but also kernel <> guest transitions.
Catalin, Will: this patch and the next o
From: Rik van Riel
Rename context_tracking_user_enter & context_tracking_user_exit
to just context_tracking_enter & context_tracking_exit, since it
will be used to track guest state, too.
This also breaks ARM. The rest of the series does not look like
it impacts ARM.
Cc: will.dea...@ar
From: Rik van Riel
Only run vtime_user_enter, vtime_user_exit, and the user enter & exit
trace points when we are entering or exiting user state, respectively.
The RCU code only distinguishes between "idle" and "not idle or kernel".
There should be no need to add an a
From: Rik van Riel
Export context_tracking_user_enter/exit so it can be used by KVM.
Signed-off-by: Rik van Riel
---
kernel/context_tracking.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 2d94147c07b2..8c5f2e939eee 100644
From: Rik van Riel
With code elsewhere doing something conditional on whether or not
context tracking is enabled, we want a stub function that tells us
context tracking is not enabled, when CONFIG_CONTEXT_TRACKING is
not set.
Signed-off-by: Rik van Riel
---
include/linux
at 10:34:21PM -0800, Paul E. McKenney
>>> 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 P
-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
> ena
-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
-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...@red
-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
>>
>> Add the expected ctx_state as a parameter to
>> cont
-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
> situ
From: Rik van Riel
Only run vtime_user_enter and vtime_user_exit when we are entering
or exiting user state, respectively.
The RCU code only distinguishes between "idle" and "not idle or kernel".
There should be no need to add an additional (unused) state there.
Signed-
From: Rik van Riel
Export context_tracking_user_enter/exit so it can be used by KVM.
Signed-off-by: Rik van Riel
---
kernel/context_tracking.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 97806c4deec5..a3f4a2840637 100644
From: Rik van Riel
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 to that used when running user space
code.
The only exception to that rule is when the host handles an
interrupt, which is
From: Rik van Riel
Add the expected ctx_state as a parameter to context_tracking_user_enter
and context_tracking_user_exit, allowing the same functions to not just
track kernel <> user space switching, but also kernel <> guest transitions.
Signed-off-by: Rik van Riel
---
i
From: Rik van Riel
With code elsewhere doing something conditional on whether or not
context tracking is enabled, we want a stub function that tells us
context tracking is not enabled, when CONFIG_CONTEXT_TRACKING is
not set.
Signed-off-by: Rik van Riel
---
include/linux
When running a KVM guest on a system with NOHZ_FULL enabled, and the
KVM guest running with idle=poll mode, we still get wakeups of the
rcuos/N threads.
This problem has already been solved for user space by telling the
RCU subsystem that the CPU is in an extended quiescent state while
running use
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
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
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 critica
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, Christi
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
>>>>
>&g
; awful latency bounds, the latency of the timer is around 8000-1 clock
> cycles compared to 2-12 without setting halt_poll. For the TSC
> deadline timer, thus, the effect is both a smaller average latency and
> a smaller variance.
>
> Signed-off-by: Paolo Bonzini
Acked-by:
From: Rik van Riel
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 to that used when running user space
code.
The only exception to that rule is when the host handles an
interrupt, which is
When running a KVM guest on a system with NOHZ_FULL enabled, and the
KVM guest running with idle=poll mode, we still get wakeups of the
rcuos/N threads.
This problem has already been solved for user space by telling the
RCU subsystem that the CPU is in an extended quiescent state while
running use
From: Rik van Riel
Add the expected ctx_state as a parameter to context_tracking_user_enter
and context_tracking_user_exit, allowing the same functions to not just
track kernel <> user space switching, but also kernel <> guest transitions.
Signed-off-by: Rik van Riel
---
i
From: Rik van Riel
Export context_tracking_user_enter/exit so it can be used by KVM.
Signed-off-by: Rik van Riel
---
kernel/context_tracking.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 97806c4deec5..a3f4a2840637 100644
From: Rik van Riel
Only run vtime_user_enter and vtime_user_exit when we are entering
or exiting user state, respectively.
The RCU code only distinguishes between "idle" and "not idle or kernel".
There should be no need to add an additional (unused) state there.
Signed-
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
>>
>> 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
>&
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
Acked-by: Rik van Riel
--
To unsubscr
xtra context switch introduces unnecessary 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
Acked-by: Rik van Riel
--
To unsubscribe from this list: send the line "unsu
On 12/11/2014 04:07 PM, Andy Lutomirski wrote:
> On Thu, Dec 11, 2014 at 12:58 PM, Marcelo Tosatti 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 wrote:
>
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
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 maj
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 sce
-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
off-by: Marcelo Tosatti
Acked-by: Rik van Riel
--
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 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) ksofti
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 unneces
ther removal
> of spte's does.
Acked-by: Rik van Riel
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUIIQiAAoJEM553pKExN6DWeoH/RpkYF1QCxnbxgZhnioaWjyu
Rp/kN6Rck6Eu3k/yRI6k+8IhgUJWkVhSXybTIDl1X6aVGgYwhaeOv2zPPfshfM6h
ABE3pLFjs2qtdotZXFSvZ
-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
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 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 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
u
notifier code is only called from the address in the PMD where
present mappings are first encountered.
The hugetlbfs code is left alone for now; hugetlb mappings are
not relocatable, and as such are left alone by the NUMA code,
and should never trigger this problem to begin with.
Signed-of
On 02/18/2014 09:24 PM, David Rientjes wrote:
> On Tue, 18 Feb 2014, r...@redhat.com wrote:
>
>> From: Rik van Riel
>>
>> The NUMA scanning code can end up iterating over many gigabytes
>> of unpopulated memory, especially in the case of a freshly started
&g
From: Rik van Riel
Reorganize the order of ifs in change_pmd_range a little, in
preparation for the next patch.
Signed-off-by: Rik van Riel
Cc: Peter Zijlstra
Cc: Andrea Arcangeli
Reported-by: Xing Gang
Tested-by: Chegu Vinod
---
mm/mprotect.c | 7 ---
1 file changed, 4 insertions
From: Rik van Riel
Normally task_numa_work scans over a fairly small amount of memory,
but it is possible to run into a large unpopulated part of virtual
memory, with no pages mapped. In that case, task_numa_work can run
for a while, and it may make sense to reschedule as required.
Signed-off
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.
This results in the mmu notifier code being called even when
there are no mapped pages in a virtual address range. The amount
of time wa
From: Rik van Riel
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.
This results in the mmu notifier code being called even when
there are no mapped pages in a virtual address range
ization 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
Signed-off-by: Andrea Arcangeli
Acked-by: Rik van Riel
--
To unsubscribe from this list: send the line "uns
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/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 i
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 autom
On 04/22/2013 05:56 PM, Andi Kleen wrote:
Rik van Riel 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 in a loop which is
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 wou
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: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 fairly
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 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 in
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/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 otherwise.
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
diff --git a/arch/x86/include/uapi/asm/kvm_para.h
b/arch/x86/include/ua
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
---
arch/x86/include/asm/paravirt.h |4 ++--
arch/x86/include/asm/paravirt_types.h |2 +-
arch/x86/kernel/kvm.c |7 ++-
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 the
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 sys
1 - 100 of 334 matches
Mail list logo
