Hi everbody,
On 5/26/24 08:40, Ole Holm Nielsen via slurm-users wrote: [...]
Whether or not to enable Hyper-Threading (HT) on your compute nodes depends entirely on the properties of applications that you wish to run on the nodes. Some applications are faster without HT, others are faster with HT. When HT is enabled, the "virtual CPU cores" obviously will have only half the memory available per core.
The VASP code is highly CPU- and memory intensive, and HT should probably be disabled for optimal performance with VASP.
Slurm doesn't affect the performance of your codes with or without HT. Slurm just schedules tasks to run on the available cores.
This is how we are handling Hyper-Threading in our cluster: * It's enabled in the BIOS/system settings. * The important parts in our slurm.conf are: TaskPlugin=task/affinity,task/cgroup CliFilterPlugins=cli_filter/lua NodeName=DEFAULT ... ThreadsPerCore=2 * We make "--hint=nomultithread" the default for jobs by having this in cli_filter.lua: function slurm_cli_setup_defaults(options, early_pass) options['hint'] = 'nomultithread' return slurm.SUCCESS end So users can still use Hyper-Threading by specifying "--hint=multithread" in their job-script which will give them two "CPUs/Threads" per Core. Without this option they will get one Core per requested CPU.
This works for us and our users. There is only one small side-effect: when a job is pending, the expected number is displayed in the "CPUS" column of the output of "squeue". But when a job is running, twice that number is displayed (as Slurm counts both Hyper-Threads per Core as "CPUs").
Regards, Hermann