On Fri, 4 May 2012 17:14:49 +0530, Srivatsa Vaddagiri
va...@linux.vnet.ibm.com wrote:
* Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2012-04-27 21:54:37]:
@@ -1549,6 +1549,11 @@ static void kvm_set_vcpu_state(struct kvm_vcpu *vcpu)
return;
vs-state = 1;
+ if
* Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2012-04-27 21:54:37]:
@@ -1549,6 +1549,11 @@ static void kvm_set_vcpu_state(struct kvm_vcpu *vcpu)
return;
vs-state = 1;
+ if (vs-flush_on_enter) {
+ kvm_mmu_flush_tlb(vcpu);
+
On Tue, 1 May 2012, Jeremy Fitzhardinge wrote:
On 05/01/2012 03:59 AM, Peter Zijlstra wrote:
On Tue, 2012-05-01 at 12:57 +0200, Peter Zijlstra wrote:
Anyway, I don't have any idea about the costs involved with
HAVE_RCU_TABLE_FREE, but I don't think its much.. otherwise these other
On Wed, 02 May 2012 12:20:40 +0200, Peter Zijlstra pet...@infradead.org wrote:
[...]
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index f96a5b5..8ca33e9 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -19,6 +19,8 @@
#include asm/pgalloc.h
On Tue, 01 May 2012 11:39:36 +0200, Peter Zijlstra pet...@infradead.org wrote:
On Sun, 2012-04-29 at 15:23 +0300, Avi Kivity wrote:
On 04/27/2012 07:24 PM, Nikunj A. Dadhania wrote:
flush_tlb_others_ipi depends on lot of statics in tlb.c. Replicated
the flush_tlb_others_ipi as
On Wed, 2012-05-02 at 14:21 +0530, Nikunj A Dadhania wrote:
[root@krm1 linux]# grep HAVE_RCU_TABLE .config
CONFIG_HAVE_RCU_TABLE_FREE=y
[root@krm1 linux]# make -j32 -s
mm/memory.c: In function ‘tlb_remove_table_one’:
mm/memory.c:315: error: implicit declaration of function
On Wed, 02 May 2012 12:20:40 +0200, Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2012-05-02 at 14:21 +0530, Nikunj A Dadhania wrote:
[root@krm1 linux]# grep HAVE_RCU_TABLE .config
CONFIG_HAVE_RCU_TABLE_FREE=y
[root@krm1 linux]# make -j32 -s
mm/memory.c: In function
On Sun, 2012-04-29 at 15:23 +0300, Avi Kivity wrote:
On 04/27/2012 07:24 PM, Nikunj A. Dadhania wrote:
flush_tlb_others_ipi depends on lot of statics in tlb.c. Replicated
the flush_tlb_others_ipi as kvm_flush_tlb_others to further adapt to
paravirtualization.
Use the vcpu state
On 05/01/2012 12:39 PM, Peter Zijlstra wrote:
On Sun, 2012-04-29 at 15:23 +0300, Avi Kivity wrote:
On 04/27/2012 07:24 PM, Nikunj A. Dadhania wrote:
flush_tlb_others_ipi depends on lot of statics in tlb.c. Replicated
the flush_tlb_others_ipi as kvm_flush_tlb_others to further adapt to
On Tue, 2012-05-01 at 13:47 +0300, Avi Kivity wrote:
On 05/01/2012 12:39 PM, Peter Zijlstra wrote:
On Sun, 2012-04-29 at 15:23 +0300, Avi Kivity wrote:
On 04/27/2012 07:24 PM, Nikunj A. Dadhania wrote:
flush_tlb_others_ipi depends on lot of statics in tlb.c. Replicated
the
On Tue, 2012-05-01 at 12:57 +0200, Peter Zijlstra wrote:
Anyway, I don't have any idea about the costs involved with
HAVE_RCU_TABLE_FREE, but I don't think its much.. otherwise these other
platforms (PPC,SPARC) wouldn't have used it, gup_fast() is a very
specific case, whereas mmu-gather is
On 05/01/2012 01:57 PM, Peter Zijlstra wrote:
Looks like this increases performance for the overcommitted case, and
also for the case where many vcpus are sleeping, while reducing
performance for the uncontended, high duty cycle case.
Sounds backwards if you put it like that ;-)
Yes...
On Tue, 2012-05-01 at 15:12 +0300, Avi Kivity wrote:
local_irq_save() is a stronger version or rcu_read_lock()
Not so, local_irq_save() doesn't at all stop regular RCU grace periods,
things like preemptible rcu can be driven from rcu_read_unlock().
Note that this is the reason call_rcu_sched()
On Tue, 2012-05-01 at 15:12 +0300, Avi Kivity wrote:
We're now moving the freeing of kvm shadow page tables from using rcu to
using an irq-protected scheme like gup_fast(), because of the
performance differences. We didn't track it down but I expect the cause
is less reuse of cache-hot pages.
On Tue, 2012-05-01 at 15:12 +0300, Avi Kivity wrote:
What's changed is not gup_fast() but the performance of munmap(),
exit(), and exec(), no?
If it is indeed cache related like you suggested earlier, it would be
the allocation side of things, like fork()/mmap() that suffer since
there's
On 05/01/2012 05:59 PM, Peter Zijlstra wrote:
On Tue, 2012-05-01 at 15:12 +0300, Avi Kivity wrote:
local_irq_save() is a stronger version or rcu_read_lock()
Not so, local_irq_save() doesn't at all stop regular RCU grace periods,
things like preemptible rcu can be driven from
On 05/01/2012 06:11 PM, Peter Zijlstra wrote:
On Tue, 2012-05-01 at 15:12 +0300, Avi Kivity wrote:
We're now moving the freeing of kvm shadow page tables from using rcu to
using an irq-protected scheme like gup_fast(), because of the
performance differences. We didn't track it down but I
On Tue, 2012-05-01 at 18:31 +0300, Avi Kivity wrote:
On 05/01/2012 05:59 PM, Peter Zijlstra wrote:
On Tue, 2012-05-01 at 15:12 +0300, Avi Kivity wrote:
local_irq_save() is a stronger version or rcu_read_lock()
Not so, local_irq_save() doesn't at all stop regular RCU grace periods,
On 05/01/2012 06:36 PM, Peter Zijlstra wrote:
On Tue, 2012-05-01 at 18:31 +0300, Avi Kivity wrote:
On 05/01/2012 05:59 PM, Peter Zijlstra wrote:
On Tue, 2012-05-01 at 15:12 +0300, Avi Kivity wrote:
local_irq_save() is a stronger version or rcu_read_lock()
Not so, local_irq_save()
On Tue, 2012-05-01 at 18:39 +0300, Avi Kivity wrote:
rcu_read_{,un}lock_sched() -- aka preempt_{en,dis}able()
call_rcu_sched()
synchronize_rcu_sched() -- aka synchronize_sched();
Define an RCU variant where each cpu has to have scheduled at least once
to complete a grace period.
On 05/01/2012 06:14 PM, Peter Zijlstra wrote:
On Tue, 2012-05-01 at 15:12 +0300, Avi Kivity wrote:
What's changed is not gup_fast() but the performance of munmap(),
exit(), and exec(), no?
If it is indeed cache related like you suggested earlier, it would be
the allocation side of
On Tue, 2012-05-01 at 18:36 +0300, Avi Kivity wrote:
What bounds the amount of memory waiting to be freed during an rcu grace
period?
Most RCU implementations don't have limits, so that could be quite a
lot. I think preemptible RCU has a batch limit at which point it tries
rather
And now with David actually on CC ;-)
On Tue, 2012-05-01 at 18:36 +0300, Avi Kivity wrote:
What bounds the amount of memory waiting to be freed during an rcu grace
period?
Most RCU implementations don't have limits, so that could be quite a
lot. I think preemptible RCU has a batch
On Tue, 2012-05-01 at 18:18 +0200, Peter Zijlstra wrote:
---
mm/oom_kill.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 46bf2ed5..244a371 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -607,6 +607,9 @@ int try_set_zonelist_oom(struct
On Tue, May 01, 2012 at 06:16:46PM +0200, Peter Zijlstra wrote:
On Tue, 2012-05-01 at 18:36 +0300, Avi Kivity wrote:
What bounds the amount of memory waiting to be freed during an rcu grace
period?
Most RCU implementations don't have limits, so that could be quite a
lot. I
On 05/01/2012 03:59 AM, Peter Zijlstra wrote:
On Tue, 2012-05-01 at 12:57 +0200, Peter Zijlstra wrote:
Anyway, I don't have any idea about the costs involved with
HAVE_RCU_TABLE_FREE, but I don't think its much.. otherwise these other
platforms (PPC,SPARC) wouldn't have used it, gup_fast() is
On Sun, 29 Apr 2012 15:23:16 +0300, Avi Kivity a...@redhat.com wrote:
On 04/27/2012 07:24 PM, Nikunj A. Dadhania wrote:
flush_tlb_others_ipi depends on lot of statics in tlb.c. Replicated
the flush_tlb_others_ipi as kvm_flush_tlb_others to further adapt to
paravirtualization.
Use the
On 04/27/2012 07:24 PM, Nikunj A. Dadhania wrote:
flush_tlb_others_ipi depends on lot of statics in tlb.c. Replicated
the flush_tlb_others_ipi as kvm_flush_tlb_others to further adapt to
paravirtualization.
Use the vcpu state information inside the kvm_flush_tlb_others to
avoid sending ipi
flush_tlb_others_ipi depends on lot of statics in tlb.c. Replicated
the flush_tlb_others_ipi as kvm_flush_tlb_others to further adapt to
paravirtualization.
Use the vcpu state information inside the kvm_flush_tlb_others to
avoid sending ipi to pre-empted vcpus.
* Do not send ipi's to offline
29 matches
Mail list logo
