<div dir="ltr">Hi Marcus,<br><div><br></div><div>This may depend on ConstrainDevices in cgroups.conf. I guess it is set to "no" in your case.</div><div><br></div><div>Best regards,</div><div>Taras<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 23, 2020 at 4:02 PM Marcus Wagner <<a href="mailto:wagner@itc.rwth-aachen.de">wagner@itc.rwth-aachen.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Kota,<br>
<br>
thanks for the hint.<br>
<br>
Yet, I'm still a little bit astonished, as if I remember right, <br>
CUDA_VISIBLE_DEVICES in a cgroup always start from zero. That has been <br>
already years ago, as we still used LSF.<br>
<br>
But SLURM_JOB_GPUS seems to be the right thing:<br>
<br>
same node, two different users (and therefore jobs)<br>
<br>
<br>
$> xargs --null --max-args=1 echo < /proc/32719/environ | egrep "GPU|CUDA"<br>
SLURM_JOB_GPUS=0<br>
CUDA_VISIBLE_DEVICES=0<br>
GPU_DEVICE_ORDINAL=0<br>
<br>
$> xargs --null --max-args=1 echo < /proc/109479/environ | egrep "GPU|CUDA"<br>
SLURM_MEM_PER_GPU=6144<br>
SLURM_JOB_GPUS=1<br>
CUDA_VISIBLE_DEVICES=0<br>
GPU_DEVICE_ORDINAL=0<br>
CUDA_ROOT=/usr/local_rwth/sw/cuda/10.1.243<br>
CUDA_PATH=/usr/local_rwth/sw/cuda/10.1.243<br>
CUDA_VERSION=101<br>
<br>
SLURM_JOB_GPU differs<br>
<br>
$> scontrol show -d job 14658274<br>
...<br>
Nodes=nrg02 CPU_IDs=24 Mem=8192 GRES_IDX=gpu:volta(IDX:1)<br>
<br>
$> scontrol show -d job 14673550<br>
...<br>
Nodes=nrg02 CPU_IDs=0 Mem=8192 GRES_IDX=gpu:volta(IDX:0)<br>
<br>
<br>
<br>
Is there anyone out there, who can confirm this besides me?<br>
<br>
<br>
Best<br>
Marcus<br>
<br>
<br>
Am 23.06.2020 um 04:51 schrieb Kota Tsuyuzaki:<br>
>> if I remember right, if you use cgroups, CUDA_VISIBLE_DEVICES always<br>
>> starts from zero. So this is NOT the index of the GPU.<br>
> <br>
> Thanks. Just FYI, when I tested the environment variables with Slurm 19.05.2 + proctrack/cgroup configuration, It looks CUDA_VISIBLE_DEVICES fits the indices on the host devices (i.e. not started from zero). I'm not sure if the behavior would be changed in the newer Slurm version though.<br>
> <br>
> I also found that SLURM_JOB_GPUS and GPU_DEVICE_ORDIGNAL was set in environment variables that can be useful. In my current tests, those variables ware being same values with CUDA_VISILE_DEVICES.<br>
> <br>
> Any advices on what I should look for, is always welcome..<br>
> <br>
> Best,<br>
> Kota<br>
> <br>
>> -----Original Message-----<br>
>> From: slurm-users <<a href="mailto:slurm-users-bounces@lists.schedmd.com" target="_blank">slurm-users-bounces@lists.schedmd.com</a>> On Behalf Of Marcus Wagner<br>
>> Sent: Tuesday, June 16, 2020 9:17 PM<br>
>> To: <a href="mailto:slurm-users@lists.schedmd.com" target="_blank">slurm-users@lists.schedmd.com</a><br>
>> Subject: Re: [slurm-users] How to view GPU indices of the completed jobs?<br>
>><br>
>> Hi David,<br>
>><br>
>> if I remember right, if you use cgroups, CUDA_VISIBLE_DEVICES always<br>
>> starts from zero. So this is NOT the index of the GPU.<br>
>><br>
>> Just verified it:<br>
>> $> nvidia-smi<br>
>> Tue Jun 16 13:28:47 2020<br>
>> +-----------------------------------------------------------------------------+<br>
>> | NVIDIA-SMI 440.44       Driver Version: 440.44       CUDA Version:<br>
>> 10.2     |<br>
>> ...<br>
>> +-----------------------------------------------------------------------------+<br>
>> | Processes:                                                       GPU<br>
>> Memory |<br>
>> |  GPU       PID   Type   Process name                             Usage<br>
>>        |<br>
>> |=========================================================================<br>
>> ====|<br>
>> |    0     17269      C   gmx_mpi<br>
>> 679MiB |<br>
>> |    1     19246      C   gmx_mpi<br>
>> 513MiB |<br>
>> +-----------------------------------------------------------------------------+<br>
>><br>
>> $> squeue -w nrg04<br>
>>                JOBID PARTITION     NAME     USER ST       TIME  NODES<br>
>> NODELIST(REASON)<br>
>>             14560009  c18g_low     egf5 bk449967  R 1-00:17:48      1 nrg04<br>
>>             14560005  c18g_low     egf1 bk449967  R 1-00:20:23      1 nrg04<br>
>><br>
>><br>
>> $> scontrol show job -d 14560005<br>
>> ...<br>
>>      Socks/Node=* NtasksPerN:B:S:C=24:0:*:* CoreSpec=*<br>
>>        Nodes=nrg04 CPU_IDs=0-23 Mem=93600 GRES_IDX=gpu(IDX:0)<br>
>><br>
>> $> scontrol show job -d 14560009<br>
>> JobId=14560009 JobName=egf5<br>
>> ...<br>
>>      Socks/Node=* NtasksPerN:B:S:C=24:0:*:* CoreSpec=*<br>
>>        Nodes=nrg04 CPU_IDs=24-47 Mem=93600 GRES_IDX=gpu(IDX:1)<br>
>><br>
>>   From the PIDs from nvidia-smi ouput:<br>
>><br>
>> $> xargs --null --max-args=1 echo < /proc/17269/environ | grep CUDA_VISIBLE<br>
>> CUDA_VISIBLE_DEVICES=0<br>
>><br>
>> $> xargs --null --max-args=1 echo < /proc/19246/environ | grep CUDA_VISIBLE<br>
>> CUDA_VISIBLE_DEVICES=0<br>
>><br>
>><br>
>> So this is only a way to see how MANY devices were used, not which.<br>
>><br>
>><br>
>> Best<br>
>> Marcus<br>
>><br>
>> Am 10.06.2020 um 20:49 schrieb David Braun:<br>
>>> Hi Kota,<br>
>>><br>
>>> This is from the job template that I give to my users:<br>
>>><br>
>>> # Collect some information about the execution environment that may<br>
>>> # be useful should we need to do some debugging.<br>
>>><br>
>>> echo "CREATING DEBUG DIRECTORY"<br>
>>> echo<br>
>>><br>
>>> mkdir .debug_info<br>
>>> module list > .debug_info/environ_modules 2>&1<br>
>>> ulimit -a > .debug_info/limits 2>&1<br>
>>> hostname > .debug_info/environ_hostname 2>&1<br>
>>> env |grep SLURM > .debug_info/environ_slurm 2>&1<br>
>>> env |grep OMP |grep -v OMPI > .debug_info/environ_omp 2>&1<br>
>>> env |grep OMPI > .debug_info/environ_openmpi 2>&1<br>
>>> env > .debug_info/environ 2>&1<br>
>>><br>
>>> if [ ! -z ${CUDA_VISIBLE_DEVICES+x} ]; then<br>
>>>           echo "SAVING CUDA ENVIRONMENT"<br>
>>>           echo<br>
>>>           env |grep CUDA > .debug_info/environ_cuda 2>&1<br>
>>> fi<br>
>>><br>
>>> You could add something like this to one of the SLURM prologs to save<br>
>>> the GPU list of jobs.<br>
>>><br>
>>> Best,<br>
>>><br>
>>> David<br>
>>><br>
>>> On Thu, Jun 4, 2020 at 4:02 AM Kota Tsuyuzaki<br>
>>> <<a href="mailto:kota.tsuyuzaki.pc@hco.ntt.co.jp" target="_blank">kota.tsuyuzaki.pc@hco.ntt.co.jp</a><br>
>>> <mailto:<a href="mailto:kota.tsuyuzaki.pc@hco.ntt.co.jp" target="_blank">kota.tsuyuzaki.pc@hco.ntt.co.jp</a>>> wrote:<br>
>>><br>
>>>      Hello Guys,<br>
>>><br>
>>>      We are running GPU clusters with Slurm and SlurmDBD (version 19.05<br>
>>>      series) and some of GPUs seemed to get troubles for attached<br>
>>>      jobs. To investigate if the troubles happened on the same GPUs, I'd<br>
>>>      like to get GPU indices of the completed jobs.<br>
>>><br>
>>>      In my understanding `scontrol show job` can show the indices (as IDX<br>
>>>      in gres info) but cannot be used for completed job. And also<br>
>>>      `sacct -j` is available for complete jobs but won't print the indices.<br>
>>><br>
>>>      Is there any way (commands, configurations, etc...) to see the<br>
>>>      allocated GPU indices for completed jobs?<br>
>>><br>
>>>      Best regards,<br>
>>><br>
>>>      --------------------------------------------<br>
>>>      露崎　浩太 (Kota Tsuyuzaki)<br>
>>>      <a href="mailto:kota.tsuyuzaki.pc@hco.ntt.co.jp" target="_blank">kota.tsuyuzaki.pc@hco.ntt.co.jp</a> <mailto:<a href="mailto:kota.tsuyuzaki.pc@hco.ntt.co.jp" target="_blank">kota.tsuyuzaki.pc@hco.ntt.co.jp</a>><br>
>>>      NTTソフトウェアイノベーションセンタ<br>
>>>      分散処理基盤技術プロジェクト<br>
>>>      0422-59-2837<br>
>>>      ---------------------------------------------<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>><br>
>> --<br>
>> Dipl.-Inf. Marcus Wagner<br>
>><br>
>> IT Center<br>
>> Gruppe: Systemgruppe Linux<br>
>> Abteilung: Systeme und Betrieb<br>
>> RWTH Aachen University<br>
>> Seffenter Weg 23<br>
>> 52074 Aachen<br>
>> Tel: +49 241 80-24383<br>
>> Fax: +49 241 80-624383<br>
>> <a href="mailto:wagner@itc.rwth-aachen.de" target="_blank">wagner@itc.rwth-aachen.de</a><br>
>> <a href="http://www.itc.rwth-aachen.de" rel="noreferrer" target="_blank">www.itc.rwth-aachen.de</a><br>
>><br>
>> Social Media Kanäle des IT Centers:<br>
>> <a href="https://blog.rwth-aachen.de/itc/" rel="noreferrer" target="_blank">https://blog.rwth-aachen.de/itc/</a><br>
>> <a href="https://www.facebook.com/itcenterrwth" rel="noreferrer" target="_blank">https://www.facebook.com/itcenterrwth</a><br>
>> <a href="https://www.linkedin.com/company/itcenterrwth" rel="noreferrer" target="_blank">https://www.linkedin.com/company/itcenterrwth</a><br>
>> <a href="https://twitter.com/ITCenterRWTH" rel="noreferrer" target="_blank">https://twitter.com/ITCenterRWTH</a><br>
>> <a href="https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ" rel="noreferrer" target="_blank">https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ</a><br>
> <br>
> <br>
> <br>
> <br>
<br>
-- <br>
Dipl.-Inf. Marcus Wagner<br>
<br>
IT Center<br>
Gruppe: Systemgruppe Linux<br>
Abteilung: Systeme und Betrieb<br>
RWTH Aachen University<br>
Seffenter Weg 23<br>
52074 Aachen<br>
Tel: +49 241 80-24383<br>
Fax: +49 241 80-624383<br>
<a href="mailto:wagner@itc.rwth-aachen.de" target="_blank">wagner@itc.rwth-aachen.de</a><br>
<a href="http://www.itc.rwth-aachen.de" rel="noreferrer" target="_blank">www.itc.rwth-aachen.de</a><br>
<br>
Social Media Kanäle des IT Centers:<br>
<a href="https://blog.rwth-aachen.de/itc/" rel="noreferrer" target="_blank">https://blog.rwth-aachen.de/itc/</a><br>
<a href="https://www.facebook.com/itcenterrwth" rel="noreferrer" target="_blank">https://www.facebook.com/itcenterrwth</a><br>
<a href="https://www.linkedin.com/company/itcenterrwth" rel="noreferrer" target="_blank">https://www.linkedin.com/company/itcenterrwth</a><br>
<a href="https://twitter.com/ITCenterRWTH" rel="noreferrer" target="_blank">https://twitter.com/ITCenterRWTH</a><br>
<a href="https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ" rel="noreferrer" target="_blank">https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ</a><br>
<br>
</blockquote></div>