Re: [Xen-devel] PML (Page Modification Logging) design for Xen

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/03/15 07:36, Kai Huang wrote:
>
>>>> It might also be nice to be able to enable or disable this feature
>>>> with a sysctl call; but that's just a nice-to-have.
>>> This feature should either be used or not.  It is impractical to
>>> enable/disable at runtime.
>>>
>>> However, it absolutely wants a knob for tweaking.  The likely
>>> consequence of a bug in the implementation is VM memory corruption on
>>> migrate, and you can get away with missing a large amount of a domains
>>> memory before it blows up noticeably.
>> Those paragraphs sound to me like they say the opposite things.
>>
>> And in any case, it's being enabled and disabled for particular
>> domains when they enable or disable logdirty mode, right?  It
>> shouldn't be hard at all to just fallback to the non-PML case if it's
>> been disabled.
>>
>> Handling the case of enabling or disabling PML on domains that are
>> already in logdirty mode is, I agree, probably more trouble than it's
>> worth.  We can just document it to say that it will only have an
>> effect on domains that start logdirty in the future.
> Currently I only plan to support PML on boot parameter, but I can
> certainly add sysctl call to enable/disable PML dynamically if you
> guys think it's necessary in the future, which should be a separate
> nice-to-have feature and won't impact existing PML functionality.
>
> Does this sound good to all of you?

I do not think a runtime switch will be useful.  The boot parameter is
useful for development, and debugging in that case that something goes
wrong, but as soon as the feature is stable I expect noone to ever tweak
the parameter again.

I certainly wouldn't focus on implementing something like this for v1. 
If a usecase develops in the future then we can certainly can reconsider.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel