Ticket 12990

Summary: threads escape the allocation
Product: Slurm Reporter: Institut Pasteur HPC Admin <hpc>
Component: SchedulingAssignee: Scott Hilton <shilton>
Status: RESOLVED DUPLICATE QA Contact:
Severity: 3 - Medium Impact    
Priority: --- CC: hpc
Version: 20.11.7   
Hardware: Linux   
OS: Linux   
Site: Institut Pasteur Slinky Site: ---
Alineos Sites: --- Atos/Eviden Sites: ---
Confidential Site: --- Coreweave sites: ---
Cray Sites: --- DS9 clusters: ---
Google sites: --- HPCnow Sites: ---
HPE Sites: --- IBM Sites: ---
NOAA SIte: --- NoveTech Sites: ---
Nvidia HWinf-CS Sites: --- OCF Sites: ---
Recursion Pharma Sites: --- SFW Sites: ---
SNIC sites: --- Tzag Elita Sites: ---
Linux Distro: --- Machine Name:
CLE Version: Version Fixed:
Target Release: --- DevPrio: ---
Emory-Cloud Sites: ---

Description Institut Pasteur HPC Admin 2021-12-08 06:30:12 MST
Hello,


we have identified a strange problem with running multi-threaded code on our cluster. In short, we allocate a number of threads for a task and run more threads than the cores allocated. It works fine at first, but after a few minutes, we can see that the threads are running on cores that were not allowed. Here is how to reproduce:

[user@maestro-submit ~]$ salloc -c 1
salloc: Pending job allocation 53430232
salloc: job 53430232 queued and waiting for resources
salloc: job 53430232 has been allocated resources
salloc: Granted job allocation 53430232
salloc: Waiting for resource configuration
salloc: Nodes maestro-1041 are ready for job

[user@maestro-1041 ~]$ srun bash -c "dd if=/dev/zero status=progress bs=1M count=102400 | pigz -p 16 -c > /dev/null"
959^Csrun: interrupt (one more within 1 sec to abort)MB/s 
srun: StepId=53430232.0 task 0: running
<running here>

so far so good, we can check that they all run on one core:
[user@maestro-1041 ~]$ ps -L -C pigz --no-headers -o psr
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8

but after few minutes:
[user@maestro-1041 ~]$ ps -L -C pigz --no-headers -o psr
  6
 22
 28
 30
 19
 41
 24
 26
 42
 23
 33
 12
 18
 14
 34
 29
 25
 40


this kind of behavior can be observed with other threaded programs (sysbench, mrand) but not with fork().

here is slurm cgroup file:
# CPUs
ConstrainCores=yes

# GPUS
ConstrainDevices=yes

# Memory
ConstrainRAMSpace=yes

and the relevant part of slurm.conf

ProctrackType=proctrack/cgroup
TaskPlugin=task/cgroup
TaskPluginParam=SlurmdOffSpec

thanks in advance for looking into it.

best regards,
   Konstantin
Comment 1 Scott Hilton 2021-12-08 15:50:20 MST
Konstantin,

We fixed a lot of issues and changed much of how cgroups works in slurm 21.08. Are you planning on upgrading soon? I don't know for sure, but the issue may be fixed already.
 
Also, we generally recommend setting "TaskPlugin=task/cgroup,task/affinity" for most situations. Is there a reason you just use "TaskPlugin=task/cgroup"?

-Scott
Comment 2 Scott Hilton 2021-12-08 16:07:08 MST
Actually, setting "TaskPlugin=task/cgroup,task/affinity" should, in fact, fix your issue.
Comment 3 Institut Pasteur HPC Admin 2021-12-14 03:05:15 MST
Hello Scott,

I'm a colleague of Konstantin.

This problem is not related at all with slurm I'm afraid. I've commented on this on case #13000: https://bugs.schedmd.com/show_bug.cgi?id=13000#c5

Sorry for opening this ticket a little too soon.

Feel free to close this case !

Jean-Baptiste
Comment 4 Jason Booth 2021-12-14 10:07:10 MST
Duplicating this out.

*** This ticket has been marked as a duplicate of ticket 13000 ***