Hi, We have Hyper-threading/SMT enabled on our cluster. It's challenging to fully utilize threads, as Brian suggests. We have a few workloads that benefit from it being enabled, but they represent a minority of our overall workload.
We use SelectTypeParameters=CR_Core_Memory. This configuration means that each thread counts as a CPU. The biggest issue with this has been user support. Most of our users are unaware of SMT as a feature and often require consultation to ensure their resource requests match their workload. I'm invested in SMT at this point, but if I had a do over (in the same environment), I would disable Hyper-threading. Ping me with questions. I'm happy to discuss our config and experience in greater detail. Sebastian -- [University of Nevada, Reno]<http://www.unr.edu/> Sebastian Smith High-Performance Computing Engineer Office of Information Technology 1664 North Virginia Street MS 0291 work-phone: 775-682-5050<tel:7756825050> email: stsm...@unr.edu<mailto:stsm...@unr.edu> website: http://rc.unr.edu<http://rc.unr.edu/> ________________________________ From: slurm-users <slurm-users-boun...@lists.schedmd.com> on behalf of Brian Andrus <toomuc...@gmail.com> Sent: Wednesday, November 4, 2020 10:12 AM To: slurm-users@lists.schedmd.com <slurm-users@lists.schedmd.com> Subject: Re: [slurm-users] Using hyperthreaded processors JC, One thing you will start finding in HPC is that, by it's goal, hyperthreading is usually a poor fit. If you are properly utilizing your cores, your jobs will actually be slowed by using hyperthreading. They are not 'extra' cores, but a method of swapping a core to a different workload during an idle cycle. The operative word being 'idle'. The goal of HPC is get resource usage as close to 100% as possible, so there should be no 'idle' cycles. >From Intel's own info: With CPU Hyper-Threading, a PC can process more information in less time and run more background tasks without disruption. In HPC, we have no background tasks (excluding daemons and such on the node), so you have little to nothing that can be improved. You end up allocating some of the various Core memory to secondary tasks instead of allowing more of it to be used by your primary task, leading to more fetches, wasting effort. This is a VERY simplistic description, but the point is that hyperthreading is not a silver bullet that will improve HPC performance if you are maximizing your resource utilization. Ok, I will get off my soapbox :) Brian Andrus On 11/4/2020 7:30 AM, Jean-Christophe HAESSIG wrote: Hi, I would like to make good use of hyperthreaded processors and I already skimmed through a quantity of posts and documentation. It is pretty clear that Slurm likes to allocate processing units up to the core level, and to be able to allocate threads one has to either : - not declare Sockets/Core/Threads at all, only CPUS and use SelectTypeParameters=CR_CPU_Memory - resort to some trickery to declare threads as cores However, the two options have shortcomings : By not declaring S/C/T, options like --ntasks-per-core seem to get ignored, but some programs would benefit from being able to be isolated on their cores. Not declaring S/C/T (e.g. C=C*T;T=1) as they are in reality also seems to mess up CPU binding since Slurm does not have a real view on the node's topology. When S/C/T are properly declared (with SelectTypeParameters= CR_Core_Memory), I run into other problems since the allocator thinks I want 2 CPUS even if I asked for --ntasks=1. In combination with --mem- per-cpu, this leads to twice memory allocated as was asked for (which resembles bug #3879). Finally, while the documentation explains in several places that processing units should be allocated best by core, I miss an explanation on why. Any other options/advice ? Feel free to correct me if I didn't get something right. Thanks, J.C. Haessig
