[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 3/8] xen: delay allocation of grant table sub structures
>>> On 11.09.17 at 11:39, <jgross@xxxxxxxx> wrote: > On 11/09/17 11:23, Jan Beulich wrote: >>>>> On 11.09.17 at 11:03, <jgross@xxxxxxxx> wrote: >>> On 08/09/17 17:28, Jan Beulich wrote: >>>>>>> On 08.09.17 at 08:56, <jgross@xxxxxxxx> wrote: >>>> And if you special case Dom0, >>>> wouldn't it be better to (also) special case the hardware domain >>>> (in case that's not Dom0)? >>> >>> As a hardware domain not being dom0 would need to be created via the >>> appropriate domctl hypercalls I don't see why the measures for all >>> other domains wouldn't be enough for that case. >> >> Yes, that's true especially when making the domctl mandatory to be >> used. Whether suitable default values for that case wouldn't better >> live in a single place (the hypervisor) is a point to be considered >> here, though (by default values I mean ones to be used when the >> config file doesn't specify any, not ones to be used by the domctl >> handler if the passed in values are zero or some other "use >> defaults" indicator, as you had elsewhere). > > But this is exactly what happens: the hypervisor defaults are being > used in case nothing is specified in the domain's config file: a value > of 0 for a value (grant table frame limit or maptrack frame limit) > specified in the domctl will just use the default values. > > Or did I misunderstand you here? Hypervisor defaults are in general meaningless when the domctl becomes mandatory (as indicated elsewhere, at least for the maptrack table size I view zero as a valid to use option). The only time hypervisor defaults would continue to be needed would be for Dom0 and, maybe (for consistency as explained) for the hardware and/or control domains. >>> Just to be sure I understand you correctly: you want to get rid of >>> INITIAL_NR_GRANT_FRAMES and just grow from 0 on instead of starting at >>> the current value 4, right? >> >> Yes, the use of INITIAL_NR_GRANT_FRAMES would move to that >> first "grow" invocation. > > Hmm, shouldn't we just grow one frame after the other? Is it really true > that most domains will need more than 1500 grants? A simple test domain > with one disk and one NIC seems to be okay with a little bit more than > 300 grants, so 1 grant table frame would be enough for that case. Yes and no. Yes because indeed many domains will not need more. No, however, because of the risk of memory shortage: By giving all domains a certain minimum, they can prepare themselves for how much (or really how little) they can do without depending on there being memory available to grow the tables later on. IOW I don't generally object to the limit being reduced, but not as a side effect of the re-work. In case of problems this needs to be easy to revert (or adjust). I.e. the change can be in the same series, but ought to be a separate patch. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |