On Wed, Oct 07, 2009 at 11:29:11AM -0400, Bill Nottingham wrote: > Richard W.M. Jones (rjones@xxxxxxxxxx) 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 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. > > Surely the way to do this is to know what your workload is doing, > and not do live migration to random hardware? Or just apply a CPUID mask to the guest, so it sees a constant set of features no matter where its migrated to. This is what Xen, VMWare, QEMU/KVM all do for this problem. Trying to make the guest re-detect, while nice in theory, is just not something people are going to bother doing - witness the death of pure paravirt, since fullyvirt is 'good enough' for most people - the same is true of CPUID masking to make hardware appear homogeneous Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
