Mailing List Archive

On 14.12.2011 11:47, Fajar A. Nugraha wrote:
>> Well... For us it make HUGE difference. We running cloud with very precise
>> accounting of fast automaric memory allocation for customer's domains and
>> we account them for ... em... KiB*hr value, so if we account domains based
>> on xc.get_domain_memkb value and customers saw difference between TotalMem
>> and our values this will make them feel like we cheating. We not greedy and
>> ready to 'cut' our mem_kb value to their TotalMem, but I hasn't found any
>> formula for that (calculate TotalMem from static-max and dom_kb values) and
>> I can't trust any data from customer's domains (except request for memory we
>> accept, serve and happily take money for 'more memory').
>>
>> It sounds ridiculous, but we avoiding pv_ops kernels usage due that little
>> ~50Mb steal. We stuck with -xen kernels (forward porting from SUSE and
>> native CentOS 2.6.18-xen). I don't know what we will do in the future, but
>> right now PV-ops is not good...
> Why not just explain what really happened in a noob-friendly language?
>
> For example, when buying a computer with built-in graphic card,
> MemTotal is always lower than the ammount of memory actually
> installed. Yet a simple explanation "some of the memory is used by the
> built-in graphic card" is enough, without having to go into details of
> what is the formula to calculate how much memory actualy used.
>
Well, this is fine if we provide customers normal 'VDS-like' virtual
machines. You getting 256MiB, some of it is used by kernel and not
displayed as TotalMem. But we provide vm with ellastic memory (like
256MiB - 8GiB) with promise 'we will serve you enough memory to your
applications and you will pay only for allocated memory for your VM'.
User expects we give him + 2GiB for 2 min and we charge him for
2*2/60=0.066 GiB*hr. With -xen kernels they got exactly they paid (at
least, with TotalMem value). If we saying them 'here something you don't
understand' this will cause some doubts.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > Looking at your BUG, did you look in the .config to see if you
> > had MAXSMP or NR_CPUS defined? If you had MAXSMP, there was a bug
> > for that fixed in 2.6.39 time-frame (I think). And if you look
> > at the NR_CPUS, do you see the NR_CPUs > 0 virtual_cpus?

Any progress on the question above?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 14.12.2011 16:16, Ian Campbell wrote:
> I take it back, there is indeed a bug in the PV ops kernel in this
> regard.
>
> It works with xm/xend because they set the maximum reservation for
> guests to static-max on boot. xl (and, I think, xapi) instead set the
> maximum reservation to the current balloon target and change it
> dynamically as the target is changed (as a method of enforcing the
> targets). However the pvops kernel incorrectly uses the maximum
> reservation at boot to size the physical address space for guests.
>
> The patch below fixes this.
>
>
(skip)

I've checked this patch against current vanilla v3.2-rc5 - it fix
problem I wrote about.

Is any chance that fix will go to release of 3.2?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Dec 15, 2011 at 04:45:41PM +0400, George Shuklin wrote:
> On 14.12.2011 16:16, Ian Campbell wrote:
> >I take it back, there is indeed a bug in the PV ops kernel in this
> >regard.
> >
> >It works with xm/xend because they set the maximum reservation for
> >guests to static-max on boot. xl (and, I think, xapi) instead set the
> >maximum reservation to the current balloon target and change it
> >dynamically as the target is changed (as a method of enforcing the
> >targets). However the pvops kernel incorrectly uses the maximum
> >reservation at boot to size the physical address space for guests.
> >
> >The patch below fixes this.
> >
> >
> (skip)
>
> I've checked this patch against current vanilla v3.2-rc5 - it fix
> problem I wrote about.

Excellent. I added a 'Reported-and-Tested-by' with your name.
>
> Is any chance that fix will go to release of 3.2?

That is the plan.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel