beth kon wrote:
Daniel Veillard wrote:
On Thu, Nov 08, 2007 at 02:00:10PM -0600, Ryan Harper wrote:
* Daniel Veillard [EMAIL PROTECTED] [2007-11-08 10:08]:
I promised that mail for the beginning of the week but I still have
I think tuning informations are that set of parameters
I tested the latest CVS libvirt on a 128-way x3950 and create, define,
and start appear to work well with various cpusets specified. The only
thing I noticed was that dumpxml does not grab the cpuset info. I have
not looked at the code to verify, but is this expected? Maybe you
discussed this
Daniel Veillard wrote:
snip
My opinion:
---
We need better tools, even for simple use case to be able to save
an existing tuning for a domain or a full machine, and reload it
when needed. This is IMHO better done on top of the existing API
which already have the entry points to
Daniel Veillard wrote:
On Wed, Oct 31, 2007 at 05:20:01PM +0900, Saori Fukuta wrote:
On Tue, 30 Oct 2007 16:54:36 -0400 Daniel Veillard wrote:
The associated patch compiles, but I have not yet tested it, it's
basically how I would expect to finish the NUMA work, but it certainly need
Daniel Veillard wrote:
On Fri, Oct 05, 2007 at 03:55:14PM -0400, beth kon wrote:
I was able to test on a 128-way NUMA box and found a bug. My code did
not handle the case of no cpus being associated with a node. I decided
to represent (pretty straightforward decision :-) no cpus as follows
Here is a resubmission of this patch, corrected.
--
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
Index: src/xend_internal.c
===
RCS file: /data/cvs/libvirt/src/xend_internal.c,v
Richard W.M. Jones wrote:
beth kon wrote:
Patch for accessing available memory.
--- libvirt.danielpatch/src/driver.h2007-09-11 15:29:43.0
-0400
+++ libvirt.cellsMemory/src/driver.h2007-09-27 18:39:52.0
-0400
@@ -258,8 +258,9 @@ typedef virDriver *virDriverPtr
Daniel P. Berrange wrote:
On Fri, Sep 28, 2007 at 02:52:51PM +0100, Richard W.M. Jones wrote:
# src/virsh capabilities
[...]
topology
cells num='1'
cell id='0'
cpus num='4'
cpu id='0'/
cpu id='1'/
cpu id='2'/
cpu id='3'/
/cpus
Richard W.M. Jones wrote:
beth kon wrote:
Patch for accessing available memory.
--- libvirt.danielpatch/src/driver.h2007-09-11 15:29:43.0
-0400
+++ libvirt.cellsMemory/src/driver.h2007-09-27 18:39:52.0
-0400
@@ -258,8 +258,9 @@ typedef virDriver *virDriverPtr
Ryan Harper wrote:
* Elizabeth Kon [EMAIL PROTECTED] [2007-09-28 11:27]:
Daniel Veillard wrote:
- isolate as a separate call what is the total sum of free memory
available
on the Node
There is currently no way to get that information from Xen.
no, we can always get
Daniel Veillard wrote:
- isolate as a separate call what is the total sum of free memory available
on the Node
There is currently no way to get that information from Xen.
- on NUMA boxes in the capability dump I would like to see the
amount of memory available on the cell see
Richard W.M. Jones wrote:
My results are a bit inconclusive. I have a machine here which
supposedly supports NUMA (2 socket, 2 core AMD with hypertransport and
two separate banks of RAM).
BIOS is _not_ configured to interleave memory. Other BIOS settings
lead me to suppose that NUMA is
Daniel,
As we discussed, here is the program I was using for testing different
topology strings.
--
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include stdio.h
#include string.h
Patch for accessing available memory.
--
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
diff -urpN libvirt.danielpatch/include/libvirt/libvirt.h.in libvirt.cellsMemory/include/libvirt/libvirt.h.in
---
Daniel Veillard wrote:
On Mon, Sep 24, 2007 at 11:29:07PM -0400, beth kon wrote:
[PATCH 1/2] - add capability to access free memory information on each
NUMA cell.
[...]
diff -urpN libvirt.danielpatch/src/xen_internal.c
libvirt.cellsMemory/src/xen_internal.c
Richard W.M. Jones wrote:
beth kon wrote:
[PATCH 1/2] - add capability to access free memory information on
each NUMA cell.
+
+/* number of cells in the node will be saved for later use */
+int nbNodeCells;
This should be static I think.
As the code stands now, I don't think so
oops... meant to post to list as well
beth kon wrote:
Daniel Veillard wrote:
On Thu, Sep 20, 2007 at 05:10:49PM -0400, beth kon wrote:
Here is my first pass at a patch for accessing the available memory
associated with each NUMA cell through libvirt.
Thanks !
Thanks for the quick
Richard W.M. Jones wrote:
beth kon wrote:
Comments on the code itself:
+ * @freeMems: pointer to the array of long long
+ * @startCell: index of first cell to return freeMems info on (0 to
+ * maxCells - 1).
+ * @maxCells: number of entries available in freeMems (-1 for sum
Here is my first pass at a patch for accessing the available memory
associated with each NUMA cell through libvirt.
The initial framework patch provided by Daniel Veillard is a prereq of
this patch:
https://www.redhat.com/archives/libvir-list/2007-September/msg00069.html
I have not yet
Daniel,
We agreed that xenHypervisorGetCapabilities will call a xend_internal.c
function to get the topology through xend.
Was your intent to extend xenDaemonNodeGetInfo or have a new function,
such as xenDaemonNodeGetTopology? I assumed a new function would be
cleaner, but you didn't
Daniel Veillard wrote:
On Fri, Sep 07, 2007 at 09:55:45AM -0400, beth kon wrote:
Daniel Veillard wrote:
which would return an XML instance as in virConnectGetCapabilities. I
toyed with the idea of extending virConnectGetCapabilities() to add a
topology section in case of NUMA support
Daniel,
I'm taking a stab at this work and want to be sure I'm taking the right
approach. I'm new to xen and even newer to libvirt, so have a bit of a
learning curve.
For the topology information, I assume that this will be a call through
xend, similar to xenDaemonNodeGetInfo. It would
Daniel Veillard wrote:
On Wed, Jun 13, 2007 at 10:40:40AM -0500, Ryan Harper wrote:
Hello all,
I wanted to start a discussion on how we might get libvirt to be able to
probe the NUMA topology of Xen and Linux (for QEMU/KVM). In Xen, I've
recently posted patches for exporting topology into
Hi. Seems to me there is a memory leak with the strdup function in
xenHypervisorMakeCapabilitiesXML. Looking up the chain of calls leading
to xenHypervisorMakeCapabilitiesXML, I don't see the required free for
the hidden malloc in the strdup. The same problem may exist with other
strdups in
24 matches
Mail list logo
