On Tue, Oct 06, 2009 at 03:05:27PM -0800, Jeff Spaleta wrote:
On Tue, Oct 6, 2009 at 2:34 PM, Richard W.M. Jones rjo...@redhat.com wrote:
which is that we should avoid making permanent optimizations, and
instead try to do runtime tests wherever possible. This is because
P2V, V2V and
On Wed, Oct 07, 2009 at 11:29:11AM -0400, Bill Nottingham wrote:
Richard W.M. Jones (rjo...@redhat.com) said:
Yup. The really fun starts when you do live migration. The processor
literally changes underneath the running programs. If you thought you
had SSE3 one minute, then the next you
On Wed, Oct 7, 2009 at 7:29 AM, Bill Nottingham nott...@redhat.com wrote:
Surely the way to do this is to know what your workload is doing,
and not do live migration to random hardware?
I think random hardware is going to be exactly what you will see a lot
of scientific research appliances
On Wed, Oct 07, 2009 at 11:29:11AM -0400, Bill Nottingham wrote:
Richard W.M. Jones (rjo...@redhat.com) said:
This is going to be pretty important for scientific workloads where
atlas is going to be used. I've eavesdropped on several conversations
where people were talking about being
Hi.
On Wed, 7 Oct 2009 11:29:11 -0400, Bill Nottingham wrote
Surely the way to do this is to know what your workload is doing,
and not do live migration to random hardware?
Redetection of CPU features in a live system is complete madness.
The virt-infrastructure has to make sure that the
On Wed, Oct 7, 2009 at 4:29 PM, Bill Nottingham nott...@redhat.com wrote:
Richard W.M. Jones (rjo...@redhat.com) said:
This is going to be pretty important for scientific workloads where
atlas is going to be used. I've eavesdropped on several conversations
where people were talking about
On Wed, Oct 07, 2009 at 06:40:38PM +0200, Ralf Ertzinger wrote:
Hi.
On Wed, 7 Oct 2009 11:29:11 -0400, Bill Nottingham wrote
Surely the way to do this is to know what your workload is doing,
and not do live migration to random hardware?
Redetection of CPU features in a live system is
Hi.
On Wed, 7 Oct 2009 19:10:28 +0100, Richard W.M. Jones wrote
If it's possible to write programs and shared library loaders so that
redetection can be performed mid-execution, then prefer that method
over one which only detects hardware when the program starts up.
I have no qualms
On Wed, Oct 07, 2009 at 08:19:07PM +0200, Ralf Ertzinger wrote:
Hi.
On Wed, 7 Oct 2009 19:10:28 +0100, Richard W.M. Jones wrote
If it's possible to write programs and shared library loaders so that
redetection can be performed mid-execution, then prefer that method
over one which only
Peter Robinson wrote:
In fact the proper way to do this it to have the same hardware in the
group of servers that VMs might be live migrated between so that its
not an issue. Then the only time this would then come into play is
when you are upgrading the group/cluster of machines to newer
On Tue, Oct 6, 2009 at 2:34 PM, Richard W.M. Jones rjo...@redhat.com wrote:
which is that we should avoid making permanent optimizations, and
instead try to do runtime tests wherever possible. This is because
P2V, V2V and virtual machine migration makes it more likely that
CPU features such
On 09-09-26 08:32:45, Kevin Kofler wrote:
...
Of course the root of the problem is ATLAS's lack of support for
runtime CPU feature detection ...
Presumably that could be added to the Fedora package as a patch. It's
SMOP to check the CPU and load the proper library, if someone who knew
how
2009/9/26 Haïkel Guémar
Right, but SSE3 ain't the least denominator of x86_64 at all.
Early AMD64 chips (3 to 5 years old) doesn't support SSE3 as x86_64
predates SSE3. You can safely assume that all AM2 socket based chips are
SSE3 enabled.
I do agree perfectly with you, however, SSE3
Deji Akingunola wrote:
i). Create a generic x86 'atlas' main package for the P6 architecture,
which is a non-SSE and minimum CPU that Fedora can support ATM.
atlas-sse, atlas-sse2, and atlas-sse3 would then be sub-packages that
users will have to specifically install to benefit from the atlas
2009/9/25 Deji Akingunola
Actually the atlas x86_64 package is using SSE3 by default. I believe
SSE3 is the least common denominator for the x86_64 cpus. And yes,
whatever is determined for the x86_32 situation will also apply for
SSE4* for x86_64.
Deji
Ok, this obviously means that
You are wrong: pni == SSE3 .
Right, but SSE3 ain't the least denominator of x86_64 at all.
Early AMD64 chips (3 to 5 years old) doesn't support SSE3 as x86_64
predates SSE3. You can safely assume that all AM2 socket based chips are
SSE3 enabled.
H.
--
fedora-devel-list mailing list
Hi there,
I don’t normally intrude on the developers list, but I’ve seen something
I believe to be factually wrong, and don’t want Fedora to make a
decision based on it:
Deji Akingunola wrote:
ii). According to smolt statistics, cpus with speeds = 512 MHz (which
is a superset of the non-SSE P6
2009/9/25 Jussi Lehtola jussileht...@fedoraproject.org:
On Fri, 2009-09-25 at 16:30 +0100, Jonathan Underwood wrote:
Well, my point was that packages that do respect CFLAGS get built
currently with certain options, and however Atlas builds, the default
package should have comparable options.
On Fri, Sep 25, 2009 at 1:10 PM, Christoph Frieben
christoph.frie...@googlemail.com wrote:
2009/9/25 Chris Adams:
(Likewise, the default x86_64 package is currently called
atlas [ atlas-sse3 ... ]
and is using SSE2 by default as expected for all x86_64 packages. Higher
Actually the
On 09/25/09 12:37, Deji Akingunola wrote:
On Fri, Sep 25, 2009 at 1:10 PM, Christoph Frieben
christoph.frie...@googlemail.com wrote:
2009/9/25 Chris Adams:
(Likewise, the default x86_64 package is currently called
atlas [ atlas-sse3 ... ]
and is using SSE2 by default as expected
20 matches
Mail list logo
