[GE users] AMD64 and EMT64 [update]

reuti reuti at staff.uni-marburg.de
Sat Aug 1 19:00:21 BST 2009


Hi,

Am 31.07.2009 um 18:51 schrieb jcd:

> Reuti-
> Thanks for your email. I wanted the built-in options for the very same
> reasons you invoked.
> For my test, I assigned the value of emt64 to lxmachine in the arch
> script (much less elegant than your simple awk program).

this should also work. I just wanted to provide a solution which will  
also work when you have a mixed cluster.

> I renamed all the directories in bin,utilbin,lib (local  
> installation). I
> stopped and restarted sge_execd
> # ps -wef  | grep sge
> sge6     15428     1  0 12:32 ?        00:00:00
> /opt/sge/bin/lx24-emt64/sge_execd
>
> However as I mentioned in my first email, no matter what I changed in
> the arch script at the local nodes, the qhost on the front end reports
> always lx24-amd64
> I am using ge-6.2u1-bin-lx24-amd64.tar.gz
>
> Am I missing something?

I saw in the past, that a node once it's added to the cluster always  
retains its first discovered architecture in qhost. Can you try to  
remove one node from SGE completely with "qconf -dh" and all entries  
in the various queues, hostgroups,... and add it again?

I used for my experiment a completely fresh installation.

-- Reuti


> JC
>
>
> reuti wrote:
>> To avoid that someone trashes his complete SGE installation: patch
>> only the stuff from the "ge62u3_lx24-amd64.tar.gz" before you untar
>> the common part. After adjusting all the things you can untar the
>> amd64 again in case you have a mixed cluster of em64t and amd64 and
>> also untar the common part.
>>
>> -- Reuti
>>
>> ===
>>
>> Hi,
>>
>> Am 30.07.2009 um 08:56 schrieb mlelstv:
>>
>>> On Tue, Jul 28, 2009 at 04:20:26PM -0400, jcd wrote:
>>>
>>>> Is it a simple way to differentiate amd64 vs emt64 without
>>>> recompiling
>>>> the SGE code (no matter what I change in arch script, qhost returns
>>>> lx24-amd64)
>>> You can assign a resource to each exechost that distinguishes  
>>> between
>>> the different processor models. If you don't want to configure this
>>> manually a load sensor can do this automatically by checking
>>> /proc/cpuinfo (on Linux).
>>
>> the advantage of having it built-in is, that you can have a mixed
>> cluster and use the predefined $ARC environment variable in your
>> jobscript to get always the correct binary out-of-the-box. This was
>> working in a mixed cluster of x86 and amd64:
>>
>> /opt/chemsoft/lx24-amd64/Gaussian_03_D.01/g03/g03
>> /opt/chemsoft/lx24-x86/Gaussian_03_D.01/g03/g03
>>
>> and you run:
>>
>> /opt/chemsoft/$ARC/Gaussian_03_D.01/g03/g03
>>
>> Whereever you land on: you get the correct binary. With the E.01
>> release already there are now also different binaries for amd64 and
>> em64t - so: what to do?
>>
>> ===
>>
>> amd64 and em64t have both 5 characters. So it seems possible to
>> change it to em64t in the arch script:
>>
>>     x86_64)
>>        lxmachine=`awk ' /vendor_id/ { if ($3 == "AuthenticAMD")
>> { print "amd64"; exit } else if ($3 == "GenuineIntel" ) { print
>> "em64t"; exit } else { print "unknown-vendor"; exit } } ' /proc/ 
>> cpuinfo`
>>        ;;
>>
>> to output the correct platform. Rename the three subdirectories in
>> "bin", "utilbin" and "lib" to lx24-em64t. Then you will have to use
>> something like:
>>
>> $ find . | xargs -n 1 sed -i -e "s/amd64/em64t/g"
>>
>> several times in your sge installation (or in a temporary directory
>> in case you want both until a
>>
>> $ grep -r amd64 *
>>
>> reveals no references to amd64 any more. Output from a patched amd64
>> w/o recompilation:
>>
>> reuti at icarus:~/sge> qhost
>> HOSTNAME                ARCH         NCPU  LOAD  MEMTOT  MEMUSE
>> SWAPTO  SWAPUS
>> --------------------------------------------------------------------- 
>> ---
>> -------
>> global                  -               -     -       -       -
>> -       -
>> qhpcg01                 lx24-em64t      4  0.16    7.8G  484.0M
>> 509.9M  120.0K
>>
>> (use on your own risk)
>>
>>
>> -- Reuti
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do? 
>> dsForumId=38&dsMessageId=210236
>>
>> To unsubscribe from this discussion, e-mail: [users- 
>> unsubscribe at gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do? 
> dsForumId=38&dsMessageId=210462
>
> To unsubscribe from this discussion, e-mail: [users- 
> unsubscribe at gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=210581

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list