On 2014/11/21 1:38, Andrea Arcangeli wrote:
Hi,
On Thu, Nov 20, 2014 at 10:54:29AM +0800, zhanghailiang wrote:
Yes, you are right. This is what i really want, bypass all non-present faults
and only track strict wrprotect faults. ;)
So, do you plan to support that in the userfault API?
Yes I think it's good idea to support wrprotect/COW faults too.
Great! Then i can expect your patches. ;)
I just wanted to understand if there was any other reason why you
needed only wrprotect faults, because the non-present faults didn't
look like a big performance concern if they triggered in addition to
wrprotect faults, but it's certainly ok to optimize them away so it's
fully optimal.
Er, you have got the answer, no special, it's only for optimality.
All it takes to differentiate the behavior should be one more bit
during registration so you can select non-present, wrprotect faults or
both. postcopy live migration would select only non-present faults,
postcopy live snapshot would select only wrprotect faults, anything
like distributed shared memory supporting shared readonly access and
exclusive write access, would select both flags.
It is really flexible in this way.
I just sent an (unfortunately) longish but way more detailed email
about live snapshotting with userfaultfd but I just wanted to give a
shorter answer here too :).
Thanks for your explanation, and your patience. It is really useful,
now i know more details about why 'fork & dump live snapshot' scenario
is not acceptable. Thanks :)
Thanks,
Andrea
.
--
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
