> 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 setting a bit or counting up would be fine. There is one advantage to the counter approach that we can make this large traveling granularity flexible. In case of the bit approach, the maximum granularity is limited to HOST_LONG_BITS. If you think this flexibility is to be useless, we would take the bit approach. By the way, this is about filling the gap of the dirty bitmap management between kvm and qemu. Do you think we should set a bit when qemu's phys_ram_dirty is 0xff or !0? Radically, if we could have a bit-based phys_ram_dirty_by_word, we may just OR the dirty bitmap of kvm with qemu in kvm_get_dirty_pages_log_range()... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
