Avi Kivity wrote:
Jeremy Fitzhardinge wrote:
Yes. It seems however that only set_pte_at/pte_update/_defer are
used under significatly long lazy mmu sections (long as in number of
updates). Is it worthwhile to bother (and risk) batching kernel pte
updates ?
Well, that depends on how expens
Jeremy Fitzhardinge wrote:
Yes. It seems however that only set_pte_at/pte_update/_defer are
used under significatly long lazy mmu sections (long as in number of
updates). Is it worthwhile to bother (and risk) batching kernel pte
updates ?
Well, that depends on how expensive each update is.
Marcelo Tosatti wrote:
On Tue, Feb 10, 2009 at 02:17:49PM -0800, Jeremy Fitzhardinge wrote:
Marcelo Tosatti wrote:
KVM's paravirt mmu pte batching has issues with, at least, kernel
updates from DEBUG_PAGEALLOC.
This has been experienced with slab allocation from irq context from
within
On Tue, Feb 10, 2009 at 02:17:49PM -0800, Jeremy Fitzhardinge wrote:
> Marcelo Tosatti wrote:
>> KVM's paravirt mmu pte batching has issues with, at least, kernel
>> updates from DEBUG_PAGEALLOC.
>>
>> This has been experienced with slab allocation from irq context from
>> within lazy mmu sections:
Marcelo Tosatti wrote:
KVM's paravirt mmu pte batching has issues with, at least, kernel
updates from DEBUG_PAGEALLOC.
This has been experienced with slab allocation from irq context from
within lazy mmu sections:
https://bugzilla.redhat.com/show_bug.cgi?id=480822
DEBUG_PAGEALLOC will map/unma
KVM's paravirt mmu pte batching has issues with, at least, kernel
updates from DEBUG_PAGEALLOC.
This has been experienced with slab allocation from irq context from
within lazy mmu sections:
https://bugzilla.redhat.com/show_bug.cgi?id=480822
DEBUG_PAGEALLOC will map/unmap the kernel pagetables
