On 23/08/17 10:36, Jan Beulich wrote: >>>> On 23.08.17 at 09:49, <jgr...@suse.com> wrote: >> On 22/08/17 14:48, Jan Beulich wrote: >>>>>> On 21.08.17 at 20:05, <jgr...@suse.com> wrote: >>>> Currently Linux has no support for grant v2 as this would reduce the >>>> maximum number of active grants by a factor of 2 compared to v1, >>>> because the number of possible grants are limited by the allowed number >>>> of grant frames and grant entries of v2 need twice as much bytes as >>>> those of v1. >>>> >>>> Unfortunately grant v2 is the only way to support either guests with >>>> more than 16TB memory size or PV guests with memory above the 16TB >>>> border, as grant v1 limits the frame number to be 32 bits wide. >>>> >>>> In order to remove the disadvantage of grant v2 this patch series >>>> enables configuring different maximum grant frame numbers for v1 and >>>> v2. >>> >>> But that does imply higher memory footprint of such a guest in Xen, >>> doesn't it? >> >> With current defaults this would need up to 128kB more for a guest using >> v2 grants. > > At least in an auto-ballooned setup this may make the difference > between a guest being able or failing to start. > >>> The limit, after all, is there to bound resource use of >>> DomU-s. I wonder whether we shouldn't make any such increase >>> dependent on first putting in place proper accounting of the memory >>> used for individual domains. >> >> So you would want to have a way to count pages (or bytes?) allocated for >> hypervisor internal needs on a per-domain basis, right? >> >> Would that be additional to struct domain -> xenheap_pages or would you >> want to merge the new counter into it? I guess a new field would be >> required in order to avoid counting some data twice. >> >> Do you have an idea what to do with that value? Do you want to expose it >> to the user (dom0 admin), or should it be used just inside the >> hypervisor and e.g. printed by a debug key handler? >> >> Do you want an additional set of allocating functions doing the >> accounting, or should the existing functions be used with an additional >> domain pointer, or should the caller be responsible doing the additional >> accounting? >> >> Do you want an all-or-nothing approach or a gradual move to add the new >> accounting step by step? > > We've been vaguely discussing this in the past on a few occasions. > My personal thinking is that the "memory=" setting in a guest config > really ought to express all the memory associated with a guest. But > of course there'll be problems with us starting to do so, and that's > beyond people observing less memory in their guests. Switching to > such a full accounting model will require some careful thought (and > discussion up front). Hence I've only said "I wonder whether", i.e. > I don't mean to make this a strict prerequisite to the proposed > changes here. I'd be in particular interested to hear opinions of a > few other people.
Fair enough. Just some thoughts on that topic from my side: This approach should be fine IMO for memory allocated while creating a domain. This is basically the same as a bare metal system where the BIOS needs some memory. Memory allocated during the lifetime of a domain is a different problem: either you allow the domain to claim more memory as configured, or you have to reserve a more or less arbitrary amount of memory to be allocated later and eventually fail such allocations. I don't think this approach is acceptable. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel