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