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@xxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
