Re: [Xen-devel] [PATCHv11 4/4] gnttab: use per-VCPU maptrack free lists

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.06.15 at 17:28, <tim@xxxxxxx> wrote:
> At 15:51 +0100 on 05 Jun (1433519478), Jan Beulich wrote:
>> Iirc before both of these changes, and the v10 ones imo should
>> have invalidated it. Tim, I'm particularly trying to understand
>> whether you're okay with the original's (potentially even heavier)
>> resource use and/or this version's (risking to run out of maptrack
>> entries _much_ earlier than currently).
> 
> The concern with the earlier version being that the maximum maptrack
> limit gets a lot higher with many vcpus?  I was OK with that.  There
> are a lot of things that scale with #vcpus, and xenheap pages are not
> particularly scarce any more.  So let's say I don't find one 128-vcpu
> guest much different from 128 1-vcpu guests for this purpose.

I certainly can see that resource consumption may scale with the
number of vCPU-s a guest has. But whether that ought to apply to
everything, i.e. including all per-domain (rather than per-vCPU)
resources (which the maptrack table is only an example of) I'm not
sure about. In the end, if we were to talk about v9 and the default
of 256 frames, a 1024-vCPU DomU could consume 1Gb of memory
for its maptrack even if (quite likely) it doesn't serve any other
guest. IOW to me it would seem that a necessary prereq to this
change would be to make the limit a per-domain setting, with only
Dom0 getting its limit bumped by default (and even then the
at-least-one-page-per-vCPU requirement undermines that, i.e. a
slow path to avoid going over the set limit would still seem
necessary).

Additionally, with the maptrack pages no longer shared across
vCPU-s, running into an allocation failure namely on ballooned
setups (where Xen typically doesn't have much memory available,
since the ballooning ordinarily only accounts for the immediate
domain needs) is going to become quite a bit more likely. Yes, I
already hear David saying "I don't care about the ballooning case",
but no, I don't think we can simply ignore this case (unless we
want to declare ballooning a deprecated, no longer supported
feature).

Jan


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