[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, Mar 12, 2015 at 7:19 PM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

Agreed.

Thanks,
-Kai

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



-- 
Thanks,
-Kai

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.