Re: Can't always start 32 bit domains after 64 bit domains

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1925 bytes --]

On Tue, 2016-11-22 at 22:40 +0100, Dario Faggioli wrote:
> On Tue, 2016-11-22 at 11:37 -0800, Sarah Newman wrote:
> > 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.
> > 
> No, I'm saying that _not_ specifying cpus= will trigger libxl
> interference. _Do_ specifying it, will either limit or disable it,
> depending on how you specify it.
> 
> That's all I'm saying.
> 
And let me just add that, the automatic NUMA placement algorithm is
very flexible and extendible.

As I said, I didn't pay much attention at this 32 bit guests memory
issue when doing it (neither did anyone reviewing the code), and I'm
sorry if this is causing troubles.

But, really, if we want to feed a constraint, or a preference about
this inside the algorithm, we can do that without much hassle, and I'm
happy to help with that.

For instance (and I'm really just thinking out loud here), let's assume
that we know memory on NUMA node 0 is what 32 bit guests need: we can
instruct the placement algorithm to either disfavour or ignore node 1
when placing a 64 bit guest.

Or something like that...

If you think this could be interesting, let's talk about it. As soon as
I'll fully understand the constraint, and we'll have agreed on an
interface (e.g., a xl.conf flag?) and on the best course of action
(e.g., disfavour vs. forbid), I can write the code myself. :-)

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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