From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: PML (Page Modification Logging) design for Xen Date: Thu, 12 Mar 2015 11:19:08 +0000 Message-ID: <5501762C.30604@citrix.com> References: <54DB129D.3060102@linux.intel.com> <54DB4294.1080406@citrix.com> <54DC1249.60507@linux.intel.com> <54E323C7020000780006089B@mail.emea.novell.com> <550022EE.8060302@citrix.com> <550141E5.5030306@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <550141E5.5030306@linux.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Kai Huang , George Dunlap Cc: Keir Fraser , "Tian, Kevin" , Tim Deegan , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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