Re: [Xen-devel] Can't always start 32 bit domains after 64 bit domains

[Sarah Newman <srn@xxxxxxxxx>]

On 11/26/2016 05:14 PM, Dario Faggioli wrote:
> 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. :-)

I don't think unconditionally allocating from the top of RAM would be kind
to most other users. Presumably most people are no longer using 32 bit
guests or this would have been found already.

It seems to me like an xl config option for setting aside memory for 32 bit
guests, similar to the one for xm, would be the best option. If  that entire
amount could be considered allocated when considering where to put 64 bit
domains, and the constraint was to balance the amount of RAM in use by each
node, I think it would do the right thing.

Or if that's too much effort, having an option to allocate down from the
top of memory for 64 bit guests (regardless of NUMA) would also work.

Thanks, Sarah



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