All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sarah Newman <srn@prgmr.com>
To: Dario Faggioli <dario.faggioli@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	LarsKurth <lars.kurth@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: Can't always start 32 bit domains after 64 bit domains
Date: Tue, 22 Nov 2016 11:37:40 -0800	[thread overview]
Message-ID: <6a400e0e-9150-5652-706d-95dc4b660f8d@prgmr.com> (raw)
In-Reply-To: <1479840405.2712.36.camel@citrix.com>

On 11/22/2016 10:46 AM, Dario Faggioli wrote:
> On Mon, 2016-11-21 at 13:06 -0800, Sarah Newman wrote:
>> On 11/21/2016 11:37 AM, Sarah Newman wrote:
>>> 
>>> If that's the reason not all the higher memory is being used first: is a potential workaround to pin 64 bit domains to the second physical
>>> core on boot, and 32 bit domains to the first physical core on boot, and then change the allowed cores with 'xl vcpu-pin' after the domain is
>>> loaded?
>> 
>> Free memory on a test server with no domains: node:    memsize    memfree    distances 0:    148480     142983      10,21 1:    147456
>> 144645      21,10
>> 
>> Free memory booting 116 256M 64-bit domains, limited to cpus='all,^0- 1' on boot: node:    memsize    memfree    distances 0:    148480
>> 128416      10,21 1:    147456     129669      21,10
>> 
>> Free memory booting 116 256M 64-bit domains, limited to cpus='12-23' on boot: node:    memsize    memfree    distances 0:    148480     143397
>> 10,21 1:    147456     114693      21,10
>> 
>> This looks like a viable workaround. Where should I document it?
>> 
> It's documented in here (although, the text can be improved a bit, I think)... look for 'cpus' and 'cpus_soft' within the page: 
> https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
> 
> A more clear mention to using "all" can perhaps be added to the wiki pages I listed in my other email.
> 

Testing shows that memory allocation is still alternated between the two physical nodes, even after setting cpus='all' or removing cpus=... from the
configuration file entirely.

If you're saying not specifying "cpus=..." will keep libxl from interfering with the Xens default allocation policy, then Xens default allocation
policy no longer starts from the top of memory for 64 bit PV domains, at least for 4.6.3. Maybe it's starting from the top of memory per node.

> However, what I think is totally missing, is any documentation about the fact that, in use cases like yours, domain creation should be done in a
> certain order, for what reasons, which order is that, and the fact that NUMA placement may interfere.
> 
> I'm not sure where and how to properly document all this [adding Lars], but I'd say it probably deserves a dedicated wiki page.
> 
> Thoughts?

A dedicated wiki page would be fine if it is sufficiently linked to. I would link to it from
https://wiki.xenproject.org/wiki/Xen_Project_Release_Features, maybe adding a footnote for "Host Limits" and/or various parameters listed therein.

--Sarah

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

  reply	other threads:[~2016-11-22 19:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3423fa13-18bd-ff7b-f44a-af015eda2eb7@prgmr.com>
2016-11-19 21:22 ` Can't always start 32 bit domains after 64 bit domains Sarah Newman
2016-11-21  8:20   ` Jan Beulich
2016-11-21  9:45     ` Sarah Newman
2016-11-21 10:05       ` Jan Beulich
2016-11-21 13:21         ` Andrew Cooper
2016-11-21 19:37           ` Sarah Newman
2016-11-21 21:06             ` Sarah Newman
2016-11-22 18:46               ` Dario Faggioli
2016-11-22 19:37                 ` Sarah Newman [this message]
2016-11-22 21:40                   ` Dario Faggioli
2016-11-27  1:14                     ` Dario Faggioli
2016-11-27  2:46                       ` Sarah Newman
2016-11-22 18:37             ` Dario Faggioli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6a400e0e-9150-5652-706d-95dc4b660f8d@prgmr.com \
    --to=srn@prgmr.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=lars.kurth@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.