From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Re: Proposed XENMEM_claim_pages hypercall: Analysis of problem and alternate solutions Date: Thu, 3 Jan 2013 10:49:49 -0800 (PST) Message-ID: References: <49049C00-89CA-4B43-9660-83B9ADC061E0@gridcentric.ca> <20121218221749.GA6332@phenom.dumpdata.com> <20121220160415.GO80837@ocelot.phlegethon.org> <500D325B-D5C1-4030-8B2F-749646ED426B@gridcentric.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <500D325B-D5C1-4030-8B2F-749646ED426B@gridcentric.ca> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andres Lagar-Cavilla Cc: "Keir (Xen.org)" , Ian Campbell , George Dunlap , Ian Jackson , Tim Deegan , xen-devel@lists.xen.org, Konrad Rzeszutek Wilk , Jan Beulich List-Id: xen-devel@lists.xenproject.org > From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > On Jan 2, 2013, at 4:43 PM, Dan Magenheimer wrote: > > I reject the omnisicient toolstack model as unimplementable [1] > > and, without it, I think you either do need a separate allocation/list, > > with all the issues that entails, or you need the proposed > > XENMEM_claim_pages hypercall to resolve memory allocation races > > (i.e. vs domain creation). > > That pretty much ends the discussion. If you ask me below to reason within the constraints your > rejection places, then that's artificial reasoning. Your rejection seems to stem from philosophical > reasons, rather than technical limitations. Well, perhaps my statement is a bit heavy-handed, but I don't see how it ends the discussion... you simply need to prove my statement incorrect! ;-) To me, that would mean pointing out any existing implementation or even university research that successfully predicts or externally infers future memory demand for guests. (That's a good approximation of my definition of an omniscient toolstack.) But let's save that for another time or thread. > Look, your hyper call doesn't kill kittens, so that's about as far as I will go in this discussion. Noted. I will look at adding kitten-killing functionality in the next revision. ;-) > My purpose here was to a) dispel misconceptions about sharing b) see if something better comes out > from a discussion between all interested mm parties. I'm satisfied insofar a). At some time I hope to understand paging/sharing more completely and apologize, Andres, if I have cast aspersions about its/your implementation, I was simply trying to use it as another example of an in-hypervisor page allocation that is not directly under the control of the toolstack. I do understand and agree that IF the toolstack is capable of intelligently managing d->max_pages across all domains, then your model for handling CoW hits will be sufficient. So... again... peace? Dan