Marcelo Tosatti wrote:
Do you have objections for submitting this patch for 2.6.28 ? The hash
lookup kills performance of pagetable write + context switch intensive
workloads.
Can you quantify?
2.6.28 is out of the question, 2.6.28.stable is possible, depending on
the actual performance
On Wed, Nov 26, 2008 at 01:12:20PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
Here it goes.
KVM: MMU: optimize set_spte for page sync
The write protect verification in set_spte is unnecessary for page sync.
Its guaranteed that, if the unsync spte was writable, the target page
does
From: Marcelo Tosatti [EMAIL PROTECTED]
The write protect verification in set_spte is unnecessary for page sync.
Its guaranteed that, if the unsync spte was writable, the target page
does not have a write protected shadow (if it had, the spte would have
been write protected under mmu_lock by
From: Marcelo Tosatti [EMAIL PROTECTED]
The write protect verification in set_spte is unnecessary for page sync.
Its guaranteed that, if the unsync spte was writable, the target page
does not have a write protected shadow (if it had, the spte would have
been write protected under mmu_lock by
Marcelo Tosatti wrote:
Here it goes.
KVM: MMU: optimize set_spte for page sync
The write protect verification in set_spte is unnecessary for page sync.
Its guaranteed that, if the unsync spte was writable, the target page
does not have a write protected shadow (if it had, the spte would have
Marcelo Tosatti wrote:
*shadow_pte can point to a different page if the guest updates
pagetable, there is a fault before resync, the fault updates the
spte with new gfn (and pfn) via mmu_set_spte. In which case the gfn
cache is updated since:
} else if (pfn !=
the reversal of can_unsync, it will
make a more readable patch. If you like, send a follow on that only
does the reversal.
Here it goes.
KVM: MMU: optimize set_spte for page sync
The write protect verification in set_spte is unnecessary for page sync.
Its guaranteed that, if the unsync spte
On Sun, Nov 23, 2008 at 12:36:29PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
The cost of hash table and memslot lookups are quite significant if the
workload is pagetable write intensive resulting in increased mmu_lock
contention.
@@ -1593,7 +1593,16 @@ static int set_spte(struct
On Mon, Nov 24, 2008 at 01:04:23PM +0100, Marcelo Tosatti wrote:
On Sun, Nov 23, 2008 at 12:36:29PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
The cost of hash table and memslot lookups are quite significant if the
workload is pagetable write intensive resulting in increased mmu_lock
The write protect verification in set_spte is unnecessary for page sync.
Its guaranteed that, if the unsync spte was writable, the target page
does not have a write protected shadow (if it had, the spte would have
been write protected under mmu_lock by rmap_write_protect before).
Same reasoning
10 matches
Mail list logo
