[Qemu-devel] Re: [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with additional inline functions.

2010-02-14 Thread Yoshiaki Tamura
Avi Kivity wrote: On 02/12/2010 04:08 AM, OHMURA Kei wrote: Why do you need a counter? It may be sufficient to set a single bit. This reduces the memory overhead and perhaps cache thrashing. Thanks for looking into this. I agree with your opinion. Our motivation here is to skip traveling when

[Qemu-devel] Re: [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with additional inline functions.

2010-02-12 Thread Avi Kivity
On 02/12/2010 04:08 AM, OHMURA Kei wrote: Why do you need a counter? It may be sufficient to set a single bit. This reduces the memory overhead and perhaps cache thrashing. Thanks for looking into this. I agree with your opinion. Our motivation here is to skip traveling when the dirty

[Qemu-devel] Re: [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with additional inline functions.

2010-02-11 Thread Avi Kivity
On 02/08/2010 12:22 PM, OHMURA Kei wrote: We think access phys_ram_dirty through inline functions is better than directly for encoupseling reason. We devided the ram in a 64 pages block. Each block has a counter, which is stored in phys_ram_dirty_by_word. It shows the number of dirty pages.

[Qemu-devel] Re: [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with additional inline functions.

2010-02-11 Thread OHMURA Kei
Why do you need a counter? It may be sufficient to set a single bit. This reduces the memory overhead and perhaps cache thrashing. Thanks for looking into this. I agree with your opinion. Our motivation here is to skip traveling when the dirty bitmap is really sparse or dense, so either