Opinions on packaging ATLAS (for the x86 architecture)

[Daniel P. Berrange]

On Wed, Oct 07, 2009 at 11:29:11AM -0400, Bill Nottingham wrote:
> Richard W.M. Jones (rjones at 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 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 :|