This patch makes "xm info" show information on xen version, compile info, number of socket/core, etc... In order to do that, it extends physinfo hypercall to return number of socket, adds few functions to libxc and extends python wrapper correspondingly. Here is the output of new "xm info": -- system : Linux host : ubuntu xen_release : 3.0-devel xen_compile_by : root@localdomain xen_compiler : gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2) xen_compile_date : Sun Jul 3 15:26:01 EST 2005 dom0_release : 2.6.11.12-xen0 dom0_version : #2 Sun Jul 3 15:39:31 EST 2005 machine : i686 logical_cpus : 1 sockets : 1 cores_per_socket : 1 hyperthreads_per_core : 1 cpu_mhz : 1094 memory : 511 free_memory : 122 -- Signed-off-by: Nguyen Anh Quynh <aquynh@gmail.com> # diffstat xminfo8.patch tools/libxc/xc.h | 20 +++++++++++++ tools/libxc/xc_misc.c | 40 +++++++++++++++++++++++++++ tools/python/xen/lowlevel/xc/xc.c | 55 +++++++++++++++++++++++++++++++++++++- tools/python/xen/xend/XendNode.py | 16 ++++++++--- xen/arch/x86/dom0_ops.c | 1 xen/common/kernel.c | 46 +++++++++++++++---------------- xen/include/public/dom0_ops.h | 1 xen/include/public/version.h | 3 ++ 8 files changed, 154 insertions(+), 28 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 3 Jul 2005, at 08:13, aq wrote:> This patch makes "xm info" show information on xen version, compile > info, number of socket/core, etc... > > In order to do that, it extends physinfo hypercall to return number of > socket, adds few functions to libxc and extends python wrapper > correspondingly.Why does the patch hideously reformat xen/common/kernel.c? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 3 Jul 2005, at 09:35, aq wrote:>> Why does the patch hideously reformat xen/common/kernel.c? > > do you mention the indentation i made for block of code in a switch()?Yes: that''s the only change you made in the file, except for a one-line change for xen_extraversion_t. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7/3/05, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> > On 3 Jul 2005, at 08:13, aq wrote: > > > This patch makes "xm info" show information on xen version, compile > > info, number of socket/core, etc... > > > > In order to do that, it extends physinfo hypercall to return number of > > socket, adds few functions to libxc and extends python wrapper > > correspondingly. > > Why does the patch hideously reformat xen/common/kernel.c?do you mention the indentation i made for block of code in a switch()? regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7/3/05, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> > On 3 Jul 2005, at 09:35, aq wrote: > > >> Why does the patch hideously reformat xen/common/kernel.c? > > > > do you mention the indentation i made for block of code in a switch()? > > Yes: that''s the only change you made in the file, except for a one-line > change for xen_extraversion_t.i always think that code inside a switch() should be indented. that is a standard coding style, no? regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 3 Jul 2005, at 09:49, aq wrote:>> Yes: that''s the only change you made in the file, except for a >> one-line >> change for xen_extraversion_t. > > i always think that code inside a switch() should be indented. that is > a standard coding style, no?The code is indented, of course, as it is already -- but neither Xen nor Linux indent the braces enclosing switch or case statements, and then indent the code one tab more. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7/3/05, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> > On 3 Jul 2005, at 09:49, aq wrote: > > >> Yes: that''s the only change you made in the file, except for a > >> one-line > >> change for xen_extraversion_t. > > > > i always think that code inside a switch() should be indented. that is > > a standard coding style, no? > > The code is indented, of course, as it is already -- but neither Xen > nor Linux indent the braces enclosing switch or case statements, and > then indent the code one tab more.ok, so please unindent that part. regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
While we''re at it, I''d suggest we add an extra level of hierarchy , ''nodes'', for NUMA, even if we have nodes hardwired to 1 at present e.g.:> logical_cpus : 1 > nodes : 1 > sockets_per_node : 1 > cores_per_socket : 1 > hyperthreads_per_core : 1Thanks, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:> While we''re at it, I''d suggest we add an extra level of hierarchy , > ''nodes'', for NUMA, even if we have nodes hardwired to 1 at present e.g.: > >>logical_cpus : 1 >>nodes : 1 >>sockets_per_node : 1 >>cores_per_socket : 1 >>hyperthreads_per_core : 1Is sockets_per_node always the same for each node (similarly for cores_per_socket and hyperthreads_per_core)? -- David Hopwood <david.nospam.hopwood@blueyonder.co.uk> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Ian Pratt wrote: > > While we''re at it, I''d suggest we add an extra level of hierarchy , > > ''nodes'', for NUMA, even if we have nodes hardwired to 1 at > present e.g.: > > > >>logical_cpus : 1 > >>nodes : 1 > >>sockets_per_node : 1 > >>cores_per_socket : 1 > >>hyperthreads_per_core : 1 > > Is sockets_per_node always the same for each node (similarly > for cores_per_socket and hyperthreads_per_core)?In systems where this wan''t the case we''d just have the ''missing cores'' permanently marked down. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7/4/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> > While we''re at it, I''d suggest we add an extra level of hierarchy , > ''nodes'', for NUMA, even if we have nodes hardwired to 1 at present e.g.: > > > logical_cpus : 1 > > nodes : 1 > > sockets_per_node : 1 > > cores_per_socket : 1 > > hyperthreads_per_core : 1ok, but from where should we extract the value of "nodes"? should we extend hypercall or just put it straightly into libxc? regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > > logical_cpus : 1 > > > nodes : 1 > > > sockets_per_node : 1 > > > cores_per_socket : 1 > > > hyperthreads_per_core : 1 > > ok, but from where should we extract the value of "nodes"? > should we extend hypercall or just put it straightly into libxc?We should definitely extend the hypercall. Best, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel