On 5/3/2016 3:24 AM, Cao, Lei wrote:
On 4/29/2016 2:19 PM, Radim Krčmář wrote:
2016-04-28 19:58+0000, Cao, Lei:
On 4/28/2016 5:13 AM, Huang, Kai wrote:
One general comment: won't it be better if you devide kvm_mt and make it
embedded to kvm_memory_slot? In my understanding the main difference
between bitmap and your log-dirty mechanism is you are using list not
bitmap, and I think make the dirty_gfn_list embedded to kvm_memory_slot
should simplify lots of your code.
It's true that one difference of the new mechanism is the use of list
instead of bitmap. Another difference is that the dirty list is per
vcpu, instead of per memory slot. This is so that the list can be updated
without holding a lock.
A writeup of alternatives behind your decision would be welcome.
Per-vcpu structures seems crucial with higher amount of VCPUs and
putting per-vcpu into kvm_memory_slots would either take much more
memory, or wouldn't scale as well.
Separating from kvm_memory_slot has its share of issues too, though,
because slot id can stand for different slots during runtime.
(Most/all can be solved by forbidding uses that lead to them, so
userspace would be to blame if memory tracking worked incorrectly.
E.g. reconfiguring a slot without pausing vcpus and draining dirty
pages.)
Good point. Our per-vcpu dirty list is separate from kvm_memory_slot. I'll
look into the changing slot id issue.
Actually my concern is, with your new mechanism to track guest dirty
pages, there will be two logdirty mechanisms (using bitmap and your
per-vcpu list), which I think is not good as it's a little bit
redundant, given both mechanisms are used for dirty page logging.
I think your main concern of current bitmap mechanism is scanning bitmap
takes lots of time, especially when only few pages get dirty, you still
have to scan the entire bitmap, which results in bad performance if you
runs checkpoint very frequently. My suggestion is, instead of
introducing two logdirty data structures, maybe you can try to use
another more efficient data structure instead of bitmap for both current
logdirty mechanism and your new interfaces. Maybe Xen's log-dirty tree
is a good reference.
Of course this is just my concern and I'll leave it to maintainers.
Thanks,
-Kai
--
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
