From 4c97337d58dfffae5821766b700cc8da8dc49109 Mon Sep 17 00:00:00 2001
From: Matthieu Hautreux <matthieu.hautreux@cea.fr>
Date: Mon, 12 Nov 2012 11:16:21 +0100
Subject: [PATCH] Correct a bug in consecutive steps management due to
asynchronous step completions
When using consecutive steps, it appears that in some cases, the time required
by the slurmstepd on the execution nodes to inform the controler of the completion
of the step is higher than the time required to request the following step.
In that scenario, the controler can reject the step by returning the error code
ESLURM_REQUESTED_NODE_CONFIG_UNAVAILABLE even if the step could be executed if
all the former steps were correctly finished.
This can be reproduced by launching consecutive steps and introducing dalys in
the spank epilog on the execution nodes.
The behavior is changed to only defer the execution of the step by returning
ESLURM_NODES_BUSY when all the available nodes are not idle considering the
former steps.
---
src/slurmctld/step_mgr.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/slurmctld/step_mgr.c b/src/slurmctld/step_mgr.c
index 490d41c4b46..e0145b16148 100644
--- a/src/slurmctld/step_mgr.c
+++ b/src/slurmctld/step_mgr.c
@@ -1223,10 +1223,9 @@ _pick_step_nodes (struct job_record *job_ptr,
usable_cpu_cnt);
if (node_tmp == NULL) {
int avail_node_cnt = bit_set_count(nodes_avail);
- if ((avail_node_cnt < node_idle_cnt) &&
- (step_spec->min_nodes <=
- (avail_node_cnt + nodes_picked_cnt +
- mem_blocked_nodes))) {
+ if (step_spec->min_nodes <=
+ (avail_node_cnt + nodes_picked_cnt +
+ mem_blocked_nodes)) {
*return_code = ESLURM_NODES_BUSY;
} else if (!bit_super_set(job_ptr->node_bitmap,
up_node_bitmap)) {
--
GitLab