Open Stack

> From: Roman Podoliaka [mailto:rpodolyaka at mirantis.com]
> Sent: September 06, 2016 11:55
> 
> Looks like we already have something like that in the virt drivers interface:
> 
> https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L205-
> L216
> 
> which is used in the resource tracker.

Thanks for the pointer. I added some constant but nonzero overhead
to the libvirt driver impl but it seems to me that this overhead calculation
happens against the overall memory pool on the compute.
I have 1G pages for instances and I have kept some 4k memory
for the host OS. The qemu memory overhead is allocated from the 4k
memory. If the compute runs out of 4k memory but still have free
1G pages then the claim is successful as overall there is free memory
however qemu or the host OS can fail as there is no free 4k memory.

Cheers,
gibi

> 
> On Tue, Sep 6, 2016 at 10:40 AM, Balázs Gibizer
> <balazs.gibizer at ericsson.com> wrote:
> > Hi,
> >
> > In our cloud we use 1G huge pages for the instance memory.
> > We started notice that qemu has a relevant memory overhead
> > per domain (something like 300MB per domain). As we use
> > huge pages for the instance memory nova scheduler makes
> > placement decision based on the available huge pages.
> > However in this situation the available host OS memory also
> > needs to be considered. Reserving host OS memory deployment
> > time is not practical as the needed reservation depends on the
> > number of instances that will be run on that host.
> >
> > Is there any plan in the nova community to use qemu
> > memory overhead in the placement decision in case of huge page
> > backed instance?
> >
> > If there is no plan, do you support the idea adding such feature to nova?
> >
> > Cheers,
> > gibi
> >
> >
> __________________________________________________________
> ________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev