[slurm-users] impact of changing SelectTypeParameters?

Vicker, Darby (JSC-EG311) darby.vicker-1 at nasa.gov
Fri May 11 08:30:26 MDT 2018

In the “other ramifications” category, if you aren’t already planning to, you might consider making this change during a maintenance period when all jobs are drained.  We tried to change from SelectType=select/linear to SelectType=select/cons_res on the fly once (via “scontrol reconfig”) and discovered that slurm can not preserve the job states with this change – all running jobs were lost.  I don’t know if changing  SelectTypeParameters would have the same result or not.  But be safe, I would stop all jobs and back up your StateSaveLocation before making that change.

From: slurm-users <slurm-users-bounces at lists.schedmd.com> on behalf of Liam Forbes <loforbes at alaska.edu>
Reply-To: Slurm User Community List <slurm-users at lists.schedmd.com>
Date: Thursday, May 10, 2018 at 7:29 PM
To: "slurm-users at lists.schedmd.com" <slurm-users at lists.schedmd.com>
Subject: [slurm-users] impact of changing SelectTypeParameters?

Might there be any "adverse" impacts to changing SelectTypeParameters=CR_CPU to SelectTypeParameters=CR_Socket_Memory? Our compute nodes are, for the most part, exclusive so users are allocated entire nodes, no sharing, for jobs. We explicitly specify CPUs, Sockets, CoresPerSocket, & ThreadsPerCore for all our compute nodes.

I assume --nodes, --ntasks, & --cpus-per-task would all work the same, for example, wouldn't they?

Would something change in the accounting that would make reporting on numbers of cpu hours or size of jobs change?
Other ramifications?

-There are uncountably more irrational fears than rational ones. -P. Dolan
Liam Forbes  loforbes at alaska.edu<mailto:loforbes at alaska.edu>  ph: 907-450-8618 fax: 907-450-8601
UAF Research Computing Systems Senior HPC Engineer              CISSP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20180511/59a5d8ba/attachment.html>

More information about the slurm-users mailing list