[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [Libvir] [RFC][PATCH 0/2] Tested NUMA patches for available memory and topology
- From: Ryan Harper <ryanh us ibm com>
- To: "Daniel P. Berrange" <berrange redhat com>
- Cc: libvir-list redhat com
- Subject: Re: [Libvir] [RFC][PATCH 0/2] Tested NUMA patches for available memory and topology
- Date: Fri, 28 Sep 2007 14:05:53 -0500
* Daniel P. Berrange <berrange redhat com> [2007-09-28 13:54]:
> On Fri, Sep 28, 2007 at 01:08:08PM -0500, Ryan Harper wrote:
> > * Daniel Veillard <veillard redhat com> [2007-09-28 12:59]:
> > > On Fri, Sep 28, 2007 at 12:41:21PM -0500, Ryan Harper wrote:
> > > > * Elizabeth Kon <eak 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.
Fair enough. Currently xen doesn't give us this information directly --
the raw SRAT table parsing includes physical addr ranges that could be
used to calculate the total size of a numa-node. I might have an old
patch that exported the physical ranges for each node as part of the
physinfo hcall -- that wasn't accepted by the Xen folks at the time.
>
> 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...
AFAIK, yes. The Xen NUMA parsing and data structures are based upon
Linux NUMA which as I understand it handles the above case.
>
> 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 -=|
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh us ibm com
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]