[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv11 4/4] gnttab: use per-VCPU maptrack free lists
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |