[Libvir] [RFC][PATCH 0/2] Tested NUMA patches for available memory and topology

Daniel P. Berrange berrange at redhat.com
Fri Sep 28 18:54:09 UTC 2007


On Fri, Sep 28, 2007 at 01:08:08PM -0500, Ryan Harper wrote:
> * Daniel Veillard <veillard at redhat.com> [2007-09-28 12:59]:
> > On Fri, Sep 28, 2007 at 12:41:21PM -0500, Ryan Harper wrote:
> > > * Elizabeth Kon <eak at us.ibm.com> [2007-09-28 12:32]:
> > > > >no, we can always get a total of _free_ memory, we just don't have a
> > > > >call for _total_ ram (ie, free and non-free) -- only what's in the heap
> > > > >(free mem).
> > > > >
> > > > > 
> > > > >
> > > > I asked DV about this off-list and he said he actually wanted total, not 
> > > > free. DV please correct me if I misunderstood.
> > > 
> > > Ah, OK - the text as written mentions _free_ - which is why I responded.
> > 
> >   It seems a bit silly to me to have topology informations about which
> > CPUs are part of the same Cell (i.e. share the same memory costs) but
> > being unable to find out how much memory is actually local to that cell.
> > Sure the current free heap on that cell helps to place new jobs but it's
> > only a temporary view.
> 
> I don't see how having the total changes anything - we need current free
> to determine where the next (even first) vm should go.

While its not technically neccessary, it will help with an UI visualization
of the host's allocation state, which IMHO is pretty important because we
need good visualization to help users understand this stuff.

BTW, does the Xen model allow for fact that you can have NUMA cells which
only have memory - ie no CPUs attached. This is something that's possible
in ia64 boxes...

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 




More information about the libvir-list mailing list