Reuti <[email protected]> writes: > Am 16.10.2012 um 19:50 schrieb Orion Poplawski: > >> With some more testing I'm seeing one major issue with dmtcp migration that >> involves migrating between different processor versions (e.g. Xeon 5400 -> >> 5500). We're running code compiled with the Intel Fortran compiler that is >> compiled with different code paths for different processors. This appears >> to be detected once at startup because if a job is migrated from an older >> processor to a newer processor the job will die with an illegal instruction >> signal. > > I would assume that the compiled application detects only once which > CPU type it's running on. You could limit this during compilation I > would assume to compile only for 5400 or older.
I don't know how proprietary libraries, such as for BLAS adjust to different ABIs, but they may set up dispatch tables initially, not on each call, so compilation options might not make any difference. I guess there are various other potential problems restarting on different hardware. >> There does not appear to be a way to restrict the migration of a job beyond >> what was already specified in the job submission, correct? I wonder if it >> would be possible to put more restrictions on a migrating job somehow. > > You can use `qalter` in the migration method to request a hostgroup or > requesting a string for the CPU type for the job before it's being killed. Presumably it would be a reasonable feature to have an option only to restart with the same resources as granted originally. -- Community Grid Engine: http://arc.liv.ac.uk/SGE/ _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
