On Wed, 2015-05-13 at 14:46 +0100, Ian Campbell wrote:
> > So what's the situation with this patch? Can it go in? Is someone
> > working on a better fix for the described problem?
>
> Stefano, Are you?
>
> Regardless it seems to me that this patch is correct in its own right,
> having maxmem_kb b
On Wed, 2015-05-13 at 08:18 +0100, Jan Beulich wrote:
> >>> On 22.04.15 at 19:55, wrote:
> > On Wed, 2015-04-22 at 17:33 +0100, Jan Beulich wrote:
> >> >>> On 22.04.15 at 17:36, wrote:
> >> > On Wed, 2015-04-22 at 15:41 +0100, Jan Beulich wrote:
> >> >> >>> On 22.04.15 at 16:01, wrote:
> >> >> >
>>> On 22.04.15 at 19:55, wrote:
> On Wed, 2015-04-22 at 17:33 +0100, Jan Beulich wrote:
>> >>> On 22.04.15 at 17:36, wrote:
>> > On Wed, 2015-04-22 at 15:41 +0100, Jan Beulich wrote:
>> >> >>> On 22.04.15 at 16:01, wrote:
>> >> > On Wed, 2015-04-22 at 13:02 +0100, Jan Beulich wrote:
>> >> >> Sa
On Wed, 2015-04-22 at 17:33 +0100, Jan Beulich wrote:
> >>> On 22.04.15 at 17:36, wrote:
> > On Wed, 2015-04-22 at 15:41 +0100, Jan Beulich wrote:
> >> >>> On 22.04.15 at 16:01, wrote:
> >> > On Wed, 2015-04-22 at 13:02 +0100, Jan Beulich wrote:
> >> >> Said commit ("libxl_set_memory_target: reta
>>> On 22.04.15 at 17:36, wrote:
> On Wed, 2015-04-22 at 15:41 +0100, Jan Beulich wrote:
>> >>> On 22.04.15 at 16:01, wrote:
>> > On Wed, 2015-04-22 at 13:02 +0100, Jan Beulich wrote:
>> >> Said commit ("libxl_set_memory_target: retain the same maxmem offset on
>> >> top of the current target") c
On Wed, 2015-04-22 at 15:41 +0100, Jan Beulich wrote:
> >>> On 22.04.15 at 16:01, wrote:
> > On Wed, 2015-04-22 at 13:02 +0100, Jan Beulich wrote:
> >> Said commit ("libxl_set_memory_target: retain the same maxmem offset on
> >> top of the current target") caused a regression for "xl mem-set"
> >>
On Wed, 22 Apr 2015, Jan Beulich wrote:
> >>> On 22.04.15 at 15:57, wrote:
> > From the description of the problem above, we have two issues:
> >
> > 1) we don't detect that maxmem is already UINT_MAX*4, so we shouldn't try
> >to increase it
> >
> > 2) unsigned int / uint64_t mismatch
> >
>
>>> On 22.04.15 at 15:57, wrote:
> From the description of the problem above, we have two issues:
>
> 1) we don't detect that maxmem is already UINT_MAX*4, so we shouldn't try
>to increase it
>
> 2) unsigned int / uint64_t mismatch
>
>
> 1) is pretty easy and might just come down to one mo
>>> On 22.04.15 at 16:01, wrote:
> On Wed, 2015-04-22 at 13:02 +0100, Jan Beulich wrote:
>> Said commit ("libxl_set_memory_target: retain the same maxmem offset on
>> top of the current target") caused a regression for "xl mem-set"
>> against Dom0: While prior to creation of the first domain this
On Wed, 2015-04-22 at 13:02 +0100, Jan Beulich wrote:
> Said commit ("libxl_set_memory_target: retain the same maxmem offset on
> top of the current target") caused a regression for "xl mem-set"
> against Dom0: While prior to creation of the first domain this works,
> the first domain creation invo
On Wed, 22 Apr 2015, Jan Beulich wrote:
> Said commit ("libxl_set_memory_target: retain the same maxmem offset on
> top of the current target") caused a regression for "xl mem-set"
> against Dom0: While prior to creation of the first domain this works,
> the first domain creation involving ballooni
Said commit ("libxl_set_memory_target: retain the same maxmem offset on
top of the current target") caused a regression for "xl mem-set"
against Dom0: While prior to creation of the first domain this works,
the first domain creation involving ballooning breaks. Due to "enforce"
not being set in the
12 matches
Mail list logo
