Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Since we are not allocating buckets and not individual nodes, a less specific reason why your job is run is placed in the job comment.  The normal code path would give the reason why the job couldn't be placed on one node.  Now the more generic "No available resources on nodes" will be used in most cases.
  • Buckets are sorted.  Individual nodes are not.  Nodes within a bucket are allocated from busy later nodes first before using completely free nodes.  This means if the two code paths were run on a single job, two different but perfectly correct node allocations would be created.  A job is either run through one or the other code path, so this is not going to be visible.
  • When free placement used when a select spec of the form -lselect=A+B+C, a node can be allocated to either A, B, or C, but not to multiple of them.  The normal algorithm would take what it needs for A, and if there was any resources left over, B or C could have them.  While this is sub-par free placement, perfect placement is not guarantied.  Even the normal node algorithm does nor provide perfect free placement.
    • Example: There are two nodes, one with 12 cpus and the other with 24 cpus.  A job with -lselect=3:ncpus=12 -l place=free:excl will run.  A job with -lselect=2:ncpus=12+1:ncpus=12 6 -lplace=free:excl will not run.  In this case, the first chunk will allocate both nodes.  The node bucket algorithm will allocate a node to either chunk, but not split it across two.

...