On 08/03/2010 02:36 AM, Anthony Liguori wrote:
On 08/02/2010 05:42 PM, Andre Przywara wrote:
Anthony Liguori wrote:
On 08/02/2010 08:49 AM, Ulrich Drepper wrote:
glibc uses the cache size information returned by cpuid to perform
optimizations. For instance, copy operations which would pollute
Hi guys,
I'm having a problem with kvm, my physical machine have 2 processor
Xeon E5520, with 8 mb cache size, when i run cat /proc/cpuinfo the
linux shows 16 processors equal.
processor : 15
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R)
Ricardo Martins wrote:
Hi guys,
I'm having a problem with kvm, my physical machine have 2 processor
Xeon E5520, with 8 mb cache size, when i run cat /proc/cpuinfo the
linux shows 16 processors equal.
processor : 15
vendor_id : GenuineIntel
cpu family : 6
model : 26
On 08/02/2010 03:51 PM, Andre Przywara wrote:
Ricardo Martins wrote:
Hi guys,
I'm having a problem with kvm, my physical machine have 2 processor
Xeon E5520, with 8 mb cache size, when i run cat /proc/cpuinfo the
linux shows 16 processors equal.
processor : 15
vendor_id :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/02/2010 05:51 AM, Andre Przywara wrote:
Do you have a use case for the cache size or is this just out of curiosity?
glibc uses the cache size information returned by cpuid to perform
optimizations. For instance, copy operations which would
Thanks for the answers...
I am creating an environment with multiple virtual servers, my main
concern is whether I have a noticeable
loss of performance because of this problem, if the answer is yes I
will find another solution for my host server.
2010/8/2 Ulrich Drepper drep...@redhat.com:
Ulrich Drepper wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/02/2010 05:51 AM, Andre Przywara wrote:
Do you have a use case for the cache size or is this just out of curiosity?
glibc uses the cache size information returned by cpuid to perform
optimizations. For instance, copy
On 08/02/2010 08:08 AM, Avi Kivity wrote:
I sent a patch to include the cache size when using -cpu host, but
this has been n'acked because the benefit is not clear.
Anthony, why was this NACKed?
I didn't NACK it.
My concern is that we're still not handling live migration with -cpu
host in
On 08/02/2010 08:49 AM, Ulrich Drepper wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/02/2010 05:51 AM, Andre Przywara wrote:
Do you have a use case for the cache size or is this just out of curiosity?
glibc uses the cache size information returned by cpuid to perform
On 08/02/2010 08:08 AM, Avi Kivity wrote:
On 08/02/2010 03:51 PM, Andre Przywara wrote:
Ricardo Martins wrote:
Hi guys,
I'm having a problem with kvm, my physical machine have 2 processor
Xeon E5520, with 8 mb cache size, when i run cat /proc/cpuinfo the
linux shows 16 processors equal.
Anthony Liguori wrote:
On 08/02/2010 08:08 AM, Avi Kivity wrote:
I sent a patch to include the cache size when using -cpu host, but
this has been n'acked because the benefit is not clear.
Anthony, why was this NACKed?
I didn't NACK it.
You are right. I am sorry if that created a
Anthony Liguori wrote:
On 08/02/2010 08:49 AM, Ulrich Drepper wrote:
glibc uses the cache size information returned by cpuid to perform
optimizations. For instance, copy operations which would pollute too
much of the cache because they are large will use non-temporal
instructions. There are
Ricardo Martins wrote:
Thanks for the answers...
I am creating an environment with multiple virtual servers, my main
concern is whether I have a noticeable
loss of performance because of this problem, if the answer is yes I
will find another solution for my host server.
For server workloads it
Anthony Liguori wrote:
On 08/02/2010 08:08 AM, Avi Kivity wrote:
On 08/02/2010 03:51 PM, Andre Przywara wrote:
I sent a patch to include the cache size when using -cpu host, but
this has been n'acked because the benefit is not clear.
Anthony, why was this NACKed? First, there are programs
On 08/02/2010 05:42 PM, Andre Przywara wrote:
Anthony Liguori wrote:
On 08/02/2010 08:49 AM, Ulrich Drepper wrote:
glibc uses the cache size information returned by cpuid to perform
optimizations. For instance, copy operations which would pollute too
much of the cache because they are large
On 08/02/2010 05:35 PM, Andre Przywara wrote:
Anthony Liguori wrote:
On 08/02/2010 08:08 AM, Avi Kivity wrote:
I sent a patch to include the cache size when using -cpu host, but
this has been n'acked because the benefit is not clear.
Anthony, why was this NACKed?
I didn't NACK it.
You are
On 08/02/2010 05:54 PM, Andre Przywara wrote:
Anthony Liguori wrote:
On 08/02/2010 08:08 AM, Avi Kivity wrote:
On 08/02/2010 03:51 PM, Andre Przywara wrote:
I sent a patch to include the cache size when using -cpu host, but
this has been n'acked because the benefit is not clear.
Anthony, why
On 08/03/2010 01:22 AM, Anthony Liguori wrote:
On 08/02/2010 08:08 AM, Avi Kivity wrote:
I sent a patch to include the cache size when using -cpu host, but
this has been n'acked because the benefit is not clear.
Anthony, why was this NACKed?
I didn't NACK it.
My concern is that we're
On 08/03/2010 02:38 AM, Anthony Liguori wrote:
Is there already a way to communicate from the target to the source?
This would allow to check for migrate-ability before we transfer any
data. Or should we handle this in a management application?
Since this is determined at startup time, it
On 08/03/2010 02:40 AM, Anthony Liguori wrote:
Yes, but virtualization is not supposed to expose the underlying
hardware. The vendor_id bit is a harder problem that I'm willing to
ignore in this discussion. I understand why we have to do this today.
Today and forever... unless one of the
20 matches
Mail list logo
