Hello,
I'm running some tests in a very small testing environment (before applying in the real scenario). My environment is only a computer with a old Intel i4 with this "lscpu" configuration: Architecture: x86_64 CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel BIOS Vendor ID: Intel(R) Corporation CPU family: 6 Model: 26 Model name: Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
"slurmd -C" returns: "CPUs=8 Boards=1 SocketsPerBoard=1 CoresPerSocket=4 ThreadsPerCore=2".
My slurm.conf is configured with: SelectType=select/cons_tres SelectTypeParameters=CR_Core AccountingStorageTRES=cpu,mem,node,billing,fs/disk,vmem,pages
After running a simple "helloworld" test, I have noticed that if SelectTypeParameters=CR_Core, system always reserves me an even number of CPUs (during "pending" time, I can see the real number I have requested, but when job starts "running", that number is increased to the next even number). Howerver, if I reconfigure slurm with SelectTypeParameters=CR_CPU, system reserves me the correct number of CPUs (during "pending" time and, also, during "running" time). I suppose that my system must be configured with CR_CPU, according https://slurm.schedmd.com/cons_tres.html, but could someone confirm that?
Thanks.
After running a simple “helloworld” test, I have noticed that if SelectTypeParameters=CR_Core, system always reserves me an even number of CPUs (during “pending” time, I can see the real number I have requested, but when job starts “running”, that number is increased to the next even number).
It's not that the number is even so much as that every "thread sibling" is included in the allocation, to prevent jobs from sharing a core. Sharing a core can make a job take anywhere up to twice as long, varying based on what other job happens to be assigned its partner and how much that job happens to use shared core resources. Depending on your goals and how heterogenous your users' jobs are, such inconsistency in performance could be undesirable and worth trading for a reduction in in throughput (a reduction that may be very small anyway, depending again on the nature of your users' jobs, or even reversed, if you have multi-core jobs where the slowdown on a shared core is synchronized with exclusive cores, wasting some of their capacity).
-
Gestió Servidors -
Laura Hild