> 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). -- slurm-users mailing list -- slurm-users@lists.schedmd.com To unsubscribe send an email to slurm-users-le...@lists.schedmd.com
