[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86: set dom0's default maximum reservation to the initial number of pages
On 21/03/12 08:36, Jan Beulich wrote: >>>> On 20.03.12 at 19:21, David Vrabel <david.vrabel@xxxxxxxxxx> wrote: >> From: David Vrabel <david.vrabel@xxxxxxxxxx> >> >> If a maximum reservation for dom0 is not explictly given (i.e., no >> dom0_mem=max:MMM command line option), then set the maximum >> reservation to the initial number of pages. This is what most people >> seem to expect when they specify dom0_mem=512M (i.e., exactly 512 MB >> and no more). > > I think I had seen this before (not sure whether it came from you), > and had already NAK-ed the idea back then. Please let's not play > with the meaning of existing hypervisor options, unless the "most" > in your description can validly be replaced by "all". In this case, _I_ > am using the option in its current sense almost everywhere > (expecting to be able to balloon up beyond the initial allocation), > and it can also be useful in hotplug capable machines. If someone > wants a particular maximum, (s)he should add the respective > command line option. XenServer uses dom0_mem=752M and expects it to set the maximum reservation to 752M (if it doesn't it grinds to a halt rather spectacularly as it runs out of memory due to the extra memory used for page tables etc.). So whilst I appreciate your desire to not have to change any command lines, I don't want to either. The dom0_mem option has been historically confusing. The min, and max options don't affect the initial number of pages in a useful way (min:MMM and max:MMM are no different to simply specifying MMM). So I think we need to decide what behaviour is the best in the long term. The two options are: The current behaviour: | Initial | Max | dom0_mem=III | III | Unlimited | dom0_mem=III,max:MMM | III | MMM | dom0_mem=max:MMM | MMM | MMM | or this proposal: | Initial | Max | dom0_mem=III | III | III | dom0_mem=III,max:MMM | III | MMM | dom0_mem=max:MMM | MMM | MMM | Hmm. Having enumerated the two options, the current behaviour looks more sensible to me now... The docs still need updating and I think the min:MMM option should be deprecated. >> This change means that with Linux 3.0.5 and later kernels, >> dom0_mem=512M has the same result as older, 'classic Xen' kernels. The >> older kernels used the initial number of pages to set the maximum >> number of pages and did not query the hypervisor for the maximum >> reservation. > > If the pv-ops kernels behave differently in this aspect than the forward > ported ones, then it should really be the newer one to get adjusted to > the original behavior (if so intended), unless the old behavior was > completely insane. Adjusting the hypervisor for a shortcoming(?) in a > particular implementation of a Dom0 kernel doesn't seem to be the right > route - please also consider non-Linux Dom0 kernels that might expect > the current behavior. The old behaviour did not allow dom0 to balloon up beyond the initial allocation so we don't what to go back to that. >> It is still possible to have a larger reservation by explicitly >> specifying dom0_mem=max:MMM. > > I am not intending to update dozens of command lines. Looks like I will be though... >> Keir, >> >> Suggest waiting for an Ack from Konrad (I think it results in the >> behaviour we want but would prefer it if Konrad confirmed). >> >> Also consider for 4.1. >> >> Thanks. >> >> David >> >> docs/misc/xen-command-line.markdown | 8 +++++++- >> xen/arch/x86/domain_build.c | 10 ++++++++++ >> 2 files changed, 17 insertions(+), 1 deletions(-) >> >> diff --git a/docs/misc/xen-command-line.markdown >> b/docs/misc/xen-command-line.markdown >> index beb8462..0798700 100644 >> --- a/docs/misc/xen-command-line.markdown >> +++ b/docs/misc/xen-command-line.markdown >> @@ -221,12 +221,18 @@ Specify the total size for dom0. >> ### dom0\_mem (x86) >> > `= List of ( min:<value> | max: <value> | <value> )` >> >> -each `<value>` is a size parameter. If the size is positive, it represents >> an >> absolute value. If the size is negative, the size specified is subtracted >> from the total available memory. >> +Specify the amount of memory for the initial domain (dom0) and the maximum >> reservation (the maximum amount of memory that dom0 can be increased or >> ballooned to). >> + >> +Each `<value>` is a size parameter. If the size is positive, it represents >> an absolute value. If the size is negative, the size specified is >> subtracted >> from the total available memory. >> >> * `min:<value>` specifies the minimum amount of memory allocated to dom0. >> * `max:<value>` specifies the maximum amount of memory allocated to dom0. >> * `<value>` specified the exact amount of memory allocated to dom0. >> >> +If `max:<value>` is specified then this sets the maximum reservation, >> otherwise the maximum reservation is set to the amount of memory allocated >> to >> dom0. >> + >> +For example, with `dom0_mem=512M`, dom0 starts with 512 MB and cannot >> balloon up any more. With `dom0_mem=512M,max:2G`, dom0 starts with 512 MB of >> memory and can balloon up to 2 GB. >> + >> ### dom0\_shadow >> ### dom0\_vcpus\_pin >> > `= <boolean>` >> diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c >> index b3c5d4c..0c09abc 100644 >> --- a/xen/arch/x86/domain_build.c >> +++ b/xen/arch/x86/domain_build.c >> @@ -253,6 +253,16 @@ static unsigned long __init compute_dom0_nr_pages( >> } >> #endif >> >> + /* >> + * Set dom0's maximum reservation. >> + * >> + * If no maximum was set with dom0_mem=max:MMM, then the maximum >> + * is the same as the initial number of pages. This is so >> + * dom0_mem=MMM gives the behaviour most people expect (i.e., this >> + * much RAM and no more). >> + */ >> + if ( max_pages == LONG_MAX ) >> + max_pages = nr_pages; >> d->max_pages = min_t(unsigned long, max_pages, UINT_MAX); >> >> return nr_pages; _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |