The man page for slurm.conf, select/cons_res parameter SelectTypeParameters, values CR_Socket and CR_Socket_Memory states the following:

"Note that jobs requesting one CPU will only be given access to that one CPU"

I think this statement is incorrect, or at least very misleading to users. A job requesting one CPU will only be allocated one CPU, but unless task/affinity is enabled or some other CPU binding mechanism is used, the job can access all of the CPUs on the node.  That is, a task that is distributed to the node can run on any of the CPUs on the node, not just on the one CPU that was allocated to its job. I propose the following patch to replace "given access to" with "allocated".

Regards,
Martin Perry

Fix cosmetic sacctmgr issue where if the user you are trying to add doesn't exist in the /etc/passwd file and the account you are trying to add them to doesn't exist it would print (null) instead of the bad account name.

Fixes bug reported by Bill Brophy, Bull.

    Dennis Leepow.

    as UID values. Patch from Dennis Leepow.

    a constraint field with a count (e.g. "srun --constraint=gpu*2 -N4 a.out").

The change resulted in some cases where job steps were allocated zero
CPUs on some nodes.

CPU count that is a multiple of the plane size

    Previously may report expected start time. Do for mysql, pgsql and filetxt
    plugins in this patch.

    Previously may report expected start time.

this should have no impact on a live system.

    allocate tasks in blocks of the plane size.

    dependency that can not be satisfied.

    just setting the priority to 1.

  options.

Improve handling of job updates when using limits in accounting, and updating jobs as a non-admin user.

actual and configured values 

was going through re-size logic instead of just returning OK for no-op

This prevents preserving PreemptMode from an old slurm.conf after a reconfig

Clear pending job's start_time between executions of sched/backfill.