Signed-off-by: Stefan Beller <sbel...@google.com>
---
I agree the commit 7087c5f3 (SQUASH??? on top of run-command: add an
asynchronous parallel child processor) makes sense; I arrived at the same
patch after adding in the feedback.
However I have the difference below, which I think could also be squashed in.
when we operate under the assumption that the CPUs are the bottleneck in
the case of parallelism.
run-command.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/run-command.c b/run-command.c
index b6d8b39..e9722ff 100644
--- a/run-command.c
+++ b/run-command.c
@@ -1107,8 +1107,13 @@ static void pp_collect_finished(struct
parallel_processes *pp)
}
}
-
-#define SPAWN_CAP (pp.max_processes + 1) /* spawn as many as possible */
+/*
+ * Throttle spawning children when starting the asynchronous processing,
+ * such that the first process to produce output is not slowed down to
+ * enable the fastest early feedback to the user.
+ */
+#define SPAWN_CAP (pp.max_processes + 1 < online_cpus() - 1 ? \
+ pp.max_processes + 1 : online_cpus() - 1)
int run_processes_parallel(int n, void *data,
get_next_task_fn get_next_task,
--
2.5.0.273.g6fa2560.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
