Opinions on packaging ATLAS (for the x86 architecture)

Richard W.M. Jones rjones at redhat.com
Wed Oct 7 09:30:55 UTC 2009


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 <rjones at 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 as SSE* can change unexpectedly.
> 
> 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 able to run off-the-shelf
> science code virtual appliance in order to reduce the environment
> configuration workload for an individual researcher.

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 don't, or vice versa.

No one has to my knowledge come up with a good way to deal with this.
But it probably involves signalling the kernel and processes so that
they can redo processor detection.  You can see why that is not going
to be pleasant.

At the moment it's done by masking out processor flags or by limiting
migrations to known good combinations of hardware.  However that
reduces the utility of the hardware and makes system administration
more complex.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v




More information about the fedora-devel-list mailing list