Open Stack

----- Original Message -----
> Hi Liuji,
> 
> I'm the owner of bp support-libvirt-vcpu-topology,
> There are four main reasons that I did not continue to work on it:
> 1. the design proposal has not confirmed by core developers of nova
> 2. this bp is not accepted in Icehouse development stage
> 3. Daniel expects that this bp should consider together with the other one
> numa-aware-cpu-binding, but I have no idea to do this for now

This is probably only the tip of the iceberg, and I notice Dan has now raised a new BP [1] to try and consolidate these efforts, but in the first instance it may be desirable for the image to specific a cell, socket, core, and thread based topology - not just a socket, core, and thread based topology as previously proposed. There are of course still questions to be answered about how to ensure the scheduler has enough knowledge of NUMA cell layout from Libvirt to place these guests ideally and what ideal NUMA placement might actually look like in both these cases and the more general case where no specific topology is requested.

-Steve

[1] https://blueprints.launchpad.net/nova/+spec/nova-virt-numa-and-vcpu-topology

> 4. I have no enough time to do this at this moment
> 
> 2014-03-05
> 
> 
> 
> Wangpan
> 
> 
> 
> 发件人："Liuji (Jeremy)" <jeremy.liu at huawei.com>
> 发送时间：2014-03-05 15:02
> 主题：Re: [openstack-dev] [nova] Questions about guest NUMA and memory binding
> policies
> 收件人："OpenStack Development Mailing List (not for usage
> questions)"<openstack-dev at lists.openstack.org>
> 抄送："Luohao \(brian\)"<brian.luohao at huawei.com>,"Yuanjing
> \(D\)"<yj.yuan at huawei.com>
> 
> Hi Steve,
> 
> Thanks for your reply.
> 
> I didn't know why the blueprint numa-aware-cpu-binding seems to have no more
> progress until read the two mails mentioned in your mail.
> 
> The use case analysis in the mails are very clear, they are also what I
> concern about.
> I agree that we shouldn't provide pCPU/vCPU mapping for the ending user and
> how to provide them for the user need more consideration.
> 
> The use cases I concern more are the pCPU's exclusively use(pCPU:vCPU=1:1)
> and the guest numa.
> 
> 
> Thanks,
> Jeremy Liu
> 
> 
> > -----Original Message-----
> > From: Steve Gordon [mailto:sgordon at redhat.com]
> > Sent: Tuesday, March 04, 2014 10:29 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Cc: Luohao (brian); Yuanjing (D)
> > Subject: Re: [openstack-dev] [nova] Questions about guest NUMA and memory
> > binding policies
> >  
> > ----- Original Message -----
> > > Hi, all
> > > 
> > > I search the current blueprints and old mails in the mail list, but
> > > find nothing about Guest NUMA and setting memory binding policies.
> > > I just find a blueprint about vcpu topology and a blueprint about CPU
> > > binding.
> > > 
> > > https://blueprints.launchpad.net/nova/+spec/support-libvirt-vcpu-topol
> > > ogy https://blueprints.launchpad.net/nova/+spec/numa-aware-cpu-binding
> > > 
> > > Is there any plan for the guest NUMA and memory binding policies setting?
> > > 
> > > Thanks,
> > > Jeremy Liu
> >  
> > Hi Jeremy,
> >  
> > As you've discovered there have been a few attempts at getting some work
> > started in this area. Dan Berrange outlined some of the possibilities in
> > this area
> > in a previous mailing list post [1] though it's multi-faceted, there are a
> > lot of
> > different ways to break it down. If you dig into the details you will note
> > that the
> > support-libvirt-vcpu-topology blueprint in particular got a fair way along
> > but
> > there were some concerns noted in the code reviews and on the list [2]
> > around
> > the design.
> >  
> > It seems like this is an area that there is a decent amount of interest in
> > and we
> > should work on list to flesh out a design proposal, ideally this would be
> > presented for further discussion at the Juno design summit. What are your
> > particular needs/desires from a NUMA aware nova scheduler?
> >  
> > Thanks,
> >  
> > Steve
> >  
> > [1]
> > http://lists.openstack.org/pipermail/openstack-dev/2013-November/019715.h
> > tml
> > [2]
> > http://lists.openstack.org/pipermail/openstack-dev/2013-December/022940.h
> > tml
> >  
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Steve Gordon, RHCE
Product Manager, Red Hat Enterprise Linux OpenStack Platform
Red Hat Canada (Toronto, Ontario)