On 01/17/13 17:56, Daniel P. Berrange wrote:
On Thu, Jan 17, 2013 at 05:14:30PM +0100, Peter Krempa wrote:
On 01/17/13 16:43, Daniel P. Berrange wrote:
VDSM uses the element (subelement of cpu) in the
capabilities and multiplies the numbers by the number of numa nodes.
As the data there is take
On Thu, Jan 17, 2013 at 05:14:30PM +0100, Peter Krempa wrote:
> On 01/17/13 16:43, Daniel P. Berrange wrote:
> VDSM uses the element (subelement of cpu) in the
> capabilities and multiplies the numbers by the number of numa nodes.
> As the data there is taken from nodeinfo, this breaks on some
> s
On 01/17/13 16:43, Daniel P. Berrange wrote:
I beg to differ:
"This technology is informally called CMT (Clustered Multi-Thread)
and formally called "module" by the AMD's marketing service, but
whose real name is "Clustered Integer" Core Technology. In terms of
hardware complexity and functional
On Thu, Jan 17, 2013 at 04:20:15PM +0100, Peter Krempa wrote:
> On 01/17/13 15:48, Daniel P. Berrange wrote:
> >On Thu, Jan 17, 2013 at 03:41:44PM +0100, Peter Krempa wrote:
> >>On 01/17/13 10:36, Daniel P. Berrange wrote:
>
> Well not for all machines in the wild out there. This is a very
On 01/17/13 15:48, Daniel P. Berrange wrote:
On Thu, Jan 17, 2013 at 03:41:44PM +0100, Peter Krempa wrote:
On 01/17/13 10:36, Daniel P. Berrange wrote:
Well not for all machines in the wild out there. This is a very
similar approach that libvirt uses now to detect the topology and it
is not en
On Thu, Jan 17, 2013 at 03:41:44PM +0100, Peter Krempa wrote:
> On 01/17/13 10:36, Daniel P. Berrange wrote:
> >>
> >>Well not for all machines in the wild out there. This is a very
> >>similar approach that libvirt uses now to detect the topology and it
> >>is not enough to detect threads on AMD B
On 01/17/13 10:36, Daniel P. Berrange wrote:
Well not for all machines in the wild out there. This is a very
similar approach that libvirt uses now to detect the topology and it
is not enough to detect threads on AMD Bulldozer as the cpus
corresponding to the threads have different core_id's (th
37PM -0500, Peter Krempa wrote:
> >>>>- Original Message -
> >>>>From: Daniel P. Berrange
> >>>>To: Peter Krempa
> >>>>Cc: Jiri Denemark , Amador Pahim
> >>>>, libvirt-l...@redhat.com, dougsl...@redhat.com
> &g
Cc: Jiri Denemark , Amador Pahim ,
libvirt-l...@redhat.com, dougsl...@redhat.com
Sent: Wed, 16 Jan 2013 13:39:28 -0500 (EST)
Subject: Re: [libvirt] [RFC] Data in the element in the
capabilities XML
On Wed, Jan 16, 2013 at 07:31:02PM +0100, Peter Krempa wrote:
On 01/16/13 19:11, Daniel P
empa
> >>Cc: Jiri Denemark , Amador Pahim ,
> >>libvirt-l...@redhat.com, dougsl...@redhat.com
> >>Sent: Wed, 16 Jan 2013 13:39:28 -0500 (EST)
> >>Subject: Re: [libvirt] [RFC] Data in the element in the
> >>capabilities XML
> >>
> >
:28 -0500 (EST)
Subject: Re: [libvirt] [RFC] Data in the element in the
capabilities XML
On Wed, Jan 16, 2013 at 07:31:02PM +0100, Peter Krempa wrote:
On 01/16/13 19:11, Daniel P. Berrange wrote:
On Wed, Jan 16, 2013 at 05:28:57PM +0100, Peter Krempa wrote:
Hi everybody,
a while ago
0 (EST)
> Subject: Re: [libvirt] [RFC] Data in the element in the
> capabilities XML
>
> On Wed, Jan 16, 2013 at 07:31:02PM +0100, Peter Krempa wrote:
> > On 01/16/13 19:11, Daniel P. Berrange wrote:
> > >On Wed, Jan 16, 2013 at 05:28:57PM +0100, Peter Krempa wrote:
> >
- Original Message -
From: Daniel P. Berrange
To: Peter Krempa
Cc: Jiri Denemark , Amador Pahim ,
libvirt-l...@redhat.com, dougsl...@redhat.com
Sent: Wed, 16 Jan 2013 13:39:28 -0500 (EST)
Subject: Re: [libvirt] [RFC] Data in the element in the
capabilities XML
On Wed, Jan 16
On Wed, Jan 16, 2013 at 07:31:02PM +0100, Peter Krempa wrote:
> On 01/16/13 19:11, Daniel P. Berrange wrote:
> >On Wed, Jan 16, 2013 at 05:28:57PM +0100, Peter Krempa wrote:
> >>Hi everybody,
> >>
> >>a while ago there was a discussion about changing the data that is
> >>returned in the sub-elemen
On 01/16/13 19:11, Daniel P. Berrange wrote:
On Wed, Jan 16, 2013 at 05:28:57PM +0100, Peter Krempa wrote:
Hi everybody,
a while ago there was a discussion about changing the data that is
returned in the sub-element:
x86_64
SandyBridge
Intel
The data
On Wed, Jan 16, 2013 at 05:28:57PM +0100, Peter Krempa wrote:
> Hi everybody,
>
> a while ago there was a discussion about changing the data that is
> returned in the sub-element:
>
>
>
>
> x86_64
> SandyBridge
> Intel
>
>
>
> The data provided here is as of t
Hi everybody,
a while ago there was a discussion about changing the data that is
returned in the sub-element:
x86_64
SandyBridge
Intel
The data provided here is as of today taken from the nodeinfo detection
code and thus is really wrong when the fallback m
17 matches
Mail list logo
