<div dir="ltr">Hi Jeffrey and Antony,<div><br></div><div>Thanks a lot for your valuable help and all the infos. I just tested on my PC according to your instruction while waiting for running jobs on the server to finish. It works perfectly.</div><div>I tested by setting `SelectTypeParameters=CR_CPU` and configuring `CPUS=` without specifying ` CoresPerSocket=` and `ThreadsPerCore=`. This do gives the expected behavior I am looking for.</div><div><br></div><div><br></div><div>Hi Cyrus,</div><div><br></div><div>Although have not tested on the server yet, I guess the solution above should be working correctly. Thanks!</div><div><br></div><div>The gres on the server is:</div><div><span style="font-family:monospace"><span style="color:rgb(0,0,0)">Name=gpu Type=gtx1080ti File=/dev/nvidia0
</span><br>Name=gpu Type=gtx1080ti File=/dev/nvidia1
<br>Name=gpu Type=titanv File=/dev/nvidia2
<br>Name=gpu Type=titanv File=/dev/nvidia3
<br>Name=gpu Type=titanv File=/dev/nvidia4
<br>Name=gpu Type=v100 File=/dev/nvidia5
<br>Name=gpu Type=gp100 File=/dev/nvidia6
<br>Name=gpu Type=gp100 File=/dev/nvidia7<br>
<br></span></div><div><div>The submission line is:</div><div><span style="font-family:monospace"><span style="color:rgb(0,0,0)">#!/bin/bash   </span><br>#SBATCH --job-name=US_Y285_TTP_GDP
<br>#SBATCH --output=test_%j.out
<br>#SBATCH --error=test_%j.err
<br>#SBATCH --ntasks=1
<br>#SBATCH --nodes=1
<br>#SBATCH --time=600:00:00
<br>#SBATCH --mem-per-cpu=2000
<br>#SBATCH --gres=gpu:1
<br></span></div><div><br></div><div>These just looks normal to me.</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Xiang Gao</div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Cyrus Proctor <<a href="mailto:cproctor@tacc.utexas.edu">cproctor@tacc.utexas.edu</a>> 于2019年2月8日周五 下午12:40写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div bgcolor="#FFFFFF">
<p>Xiang,</p>
<p>From what I've of the original question, gres.conf may be another place to verify the setup that only one core is being allocated per gpu request:
<a class="gmail-m_-7150438034630716168moz-txt-link-freetext" href="https://slurm.schedmd.com/gres.conf.html" target="_blank">
https://slurm.schedmd.com/gres.conf.html</a></p>
<p>Seeing the run submission line and gres.conf might help others give you further advise.</p>
<p>To Jeffrey's email: the concept of oversubscription may be beneficial versus changing resource inventories:
<a class="gmail-m_-7150438034630716168moz-txt-link-freetext" href="https://slurm.schedmd.com/cons_res_share.html" target="_blank">
https://slurm.schedmd.com/cons_res_share.html</a></p>
<p>Best,</p>
<p>Cyrus<br>
</p>
<div class="gmail-m_-7150438034630716168moz-cite-prefix">On 2/8/19 9:44 AM, Jeffrey Frey wrote:<br>
</div>
<blockquote type="cite">
Documentation for CR_CPU:
<div><br>
</div>
<div><br>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>CR_CPU</div>
<div>CPUs are consumable resources. Configure the number of CPUs on each node, which may be equal to the count of cores or hyper-threads on the node depending upon the desired minimum resource allocation. The node's Boards, Sockets, CoresPerSocket andThreadsPerCore may
 optionally be configured and result in job allocations which have improved locality;
<b>however doing so will prevent more than one job being from being allocated on each core.</b></div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>So once you're configured node(s) with ThreadsPerCore=N, the cons_res plugin still forces tasks to span all threads on a core.  Elsewhere in the documentation it is stated:</div>
<div><br>
</div>
<div><br>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><b>Note that the Slurm can allocate resources to jobs down to the resolution of a core.</b></div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>So you MUST treat a thread as a core if you want to schedule individual threads.  I can confirm this using the config:</div>
<div><br>
</div>
<div><br>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>SelectTypeParameters = CR_CPU_MEMORY</div>
<div>NodeName=n[003,008] CPUS=16 Sockets=2 CoresPerSocket=4 ThreadsPerCore=2</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Submitting a 1-cpu job, if I check the cpuset assigned to a job on n003:</div>
<div><br>
</div>
<div><br>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>$ cat /sys/fs/cgroup/cpuset/slurm/{uid}/{job}/cpuset.cpus</div>
4,12</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>If I instead configure as:</div>
<div><br>
</div>
<div><br>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>SelectTypeParameters = CR_Core_Memory</div>
<div>NodeName=n[003,008] CPUS=16 Sockets=2 CoresPerSocket=8 ThreadsPerCore=1</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Slurm will schedule "cores" 0-15 to jobs, which the cpuset cgroup happily accepts.  A 1-cpu job then shows:</div>
<div><br>
</div>
<div><br>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>$ cat /sys/fs/cgroup/cpuset/slurm/{uid}/{job}/cpuset.cpus</div>
<div>2</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>and a 2-cpu job shows:</div>
<div><br>
</div>
<div><br>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>$ cat /sys/fs/cgroup/cpuset/slurm/{uid}/{job}/cpuset.cpus</div>
<div>4,12</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<div>
<blockquote type="cite">On Feb 8, 2019, at 5:09 AM, Antony Cleave <<a href="mailto:antony.cleave@gmail.com" target="_blank">antony.cleave@gmail.com</a>> wrote:<br>
<br>
if you want slurm to just ignore the difference between physical and logical cores then you can change <br>
SelectTypeParameters=CR_Core<br>
to<br>
SelectTypeParameters=CR_CPU<br>
<br>
and then it will treat threads as CPUs and then it will let you start the number of tasks you expect<br>
<br>
Antony<br>
<br>
On Thu, 7 Feb 2019 at 18:04, Jeffrey Frey <<a href="mailto:frey@udel.edu" target="_blank">frey@udel.edu</a>> wrote:<br>
Your nodes are hyperthreaded (ThreadsPerCore=2).  Slurm always allocates _all threads_ associated with a selected core to jobs.  So you're being assigned both threads on core N.<br>
<br>
<br>
On our development-partition nodes we configure the threads as cores, e.g.<br>
<br>
<br>
NodeName=moria CPUs=16 Boards=1 SocketsPerBoard=2 CoresPerSocket=8 ThreadsPerCore=1<br>
<br>
<br>
to force Slurm to schedule the threads separately.<br>
<br>
<br>
<br>
<blockquote type="cite">On Feb 7, 2019, at 12:10 PM, Xiang Gao <a class="gmail-m_-7150438034630716168moz-txt-link-rfc2396E" href="mailto:qasdfgtyuiop@gmail.com" target="_blank">
<qasdfgtyuiop@gmail.com></a> wrote:<br>
<br>
Hi All,<br>
<br>
We configured slurm on a server with 8 GPU and 16 CPUs and want to use slurm to scheduler for both CPU and GPU jobs. We observed an unexpected behavior that, although there are 16 CPUs, slurm only schedule 8 jobs to run even if there are jobs not asking any
 GPU. If I inspect detailed information using `scontrol show job`, I see some strange thing on some job that just ask for 1 CPU:<br>
<br>
NumNodes=1 NumCPUs=2 NumTasks=1 CPUs/Task=1<br>
<br>
If I understand these concepts correctly, as the number of nodes is 1, number of tasks is 1, and number of cpus/task is 1, in principle there is no way that the final number of CPUs is 2. I'm not sure if I misunderstand the concepts, configure slurm wrongly,
 or this is a bug. So I come for help.<br>
<br>
Some related config are:<br>
<br>
# COMPUTE NODES  <br>
NodeName=moria CPUs=16 Boards=1 SocketsPerBoard=2 CoresPerSocket=4 ThreadsPerCore=2 RealMemory=120000 Gres=gpu:gtx1080ti:2,gpu:titanv:3,gpu:v100:1,gpu:gp100:2<br>
State=UNKNOWN  <br>
PartitionName=queue Nodes=moria Default=YES MaxTime=INFINITE State=UP<br>
<br>
# SCHEDULING  <br>
FastSchedule=1 <br>
SchedulerType=sched/backfill <br>
GresTypes=gpu <br>
SelectType=select/cons_res <br>
SelectTypeParameters=CR_Core<br>
<br>
Best,<br>
Xiang Gao<br>
</blockquote>
<br>
<br>
::::::::::::::::::::::::::::::::::::::::::::::::::::::<br>
Jeffrey T. Frey, Ph.D.<br>
Systems Programmer V / HPC Management<br>
Network & Systems Services / College of Engineering<br>
University of Delaware, Newark DE  19716<br>
Office: (302) 831-6034  Mobile: (302) 419-4976<br>
::::::::::::::::::::::::::::::::::::::::::::::::::::::<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
<div><br>
::::::::::::::::::::::::::::::::::::::::::::::::::::::<br>
Jeffrey T. Frey, Ph.D.<br>
Systems Programmer V / HPC Management<br>
Network & Systems Services / College of Engineering<br>
University of Delaware, Newark DE  19716<br>
Office: (302) 831-6034  Mobile: (302) 419-4976<br>
::::::::::::::::::::::::::::::::::::::::::::::::::::::<br>
<br>
<br>
<br>
</div>
<br>
</div>
</blockquote>
</div>

</blockquote></div>