If set, the job's size component will be based upon not the job size
alone, but the job's size divided by it's time limit.

The problem we have observed is the backfill scheduler temporarily
gives up its locks (one second), but then reclaims them before the
backlog of work completes, basically keeping the backfill scheduler
running for a really long time when under a heavy load.
bug 297

Defers (rather than forgets) reboot request with job running on the
node within a reservation.

Defers (rather than forgets) reboot request with job running on the
node within a reservation.

Previously nodes in a MAINT reservation would NOT reboot on demand.

all preemptable jobs on the midplane instead of just the ones it needed to.

This bug was introduced in commit f1cf6d2d
fix for bug 290

Downing the node will kill all jobs allocated to the node, very bad
on something like a BlueGene system

This can be especially useful to schedule GPUs. For example a node can be
associated with two Slurm partitions (e.g. "cpu" and "gpu") and the
partition/queue "cpu" could be limited to only a subset of the node's CPUs,
insuring that one or more CPUs would be available to jobs in the "gpu"
partition/queue.

the node tab and we didn't notice.

The option "interval" was the original parameter, but has not been
documented for a year or more.

Without this change pmdv12 was bound to one CPU and could not use
all of the resources allocated to the job step for the tasks that
it launches

This only changes behaviour when the --ntasks option is not used,
but the --cpus-per-task option is use

Also add size specification of "%0" to not limit a field size.
For example "sacct --format=%0ALL" to print everything.

also "-euidevice sn_single".

Modify slurmctld data structure locking to interleave read and write
locks rather than always favor write locks over read locks.

Make timeout configurable at build time by defining SAVE_MAX_WAIT.

Dear all,

As quick fix, I have put together this script to help manage native and symmetric MPI runs within SLURM. It's a bit bare-bones currently but I needed to get it working quickly :)

It does not provide tight integration between the scheduler and MPI daemons and requires a slot on the host, even when running fully on the MIC, so it's really far from an optimal solution but could be a stopgap.

It's inspired by the TACC Stampede documentation. They seem to have a similar script in place.

It's fairly simple, you provide the names of the MIC binary (with -m) and host binary (with -c). The host MPI/OpenMP parameters are given as usual and the Xeon Phi side parameters as environment variables (MIC_PPN, MIC_OMP_NUM_THREADS). Currently it supports only 1 card per host but extending it should be simple enough.

Here are a couple of links to documentation:

Our prototype cluster documentation:
https://confluence.csc.fi/display/HPCproto/HPC+Prototypes#HPCPrototypes-XeonPhiDevelopment
Presentation at the PRACE Spring School in Umeå earlier this week:
https://www.hpc2n.umu.se/sites/default/files/1.03%20CSC%20Cluster%20Introduction.pdf

Feel free to include this in the contribs -directory. It might need a bit of cleanup though and I don't know when I have the time to do this.

I have also added support for TotalView debugger (provided it's installed and configured properly for Xeon Phi usage).

Future ideas:

For the native MIC client, I've been testing it out a bit and looking at ways to minimize the changes needed for support. The two major challenges seem to be in scheduling and affinity:

I think it might be necessary to put it into a specific topology plugin, like the one for BG/Q, but it looks like a lot of work to do that.

Best regards,
Olli-Pekka

Avoid placing pending jobs in AdminHold state due to backfill scheduler
interactions with advanced reservation.
Specifically, if the backfill scheduler tests a pending job can be
scheduled after it's advanced reservation ends then the job was
assigned a priority of zero (AdminHold).

undefined variable.

requested and allocated.