aboutsummaryrefslogtreecommitdiff
path: root/src/util.cpp
diff options
context:
space:
mode:
authorWladimir J. van der Laan <laanwj@gmail.com>2018-04-07 19:24:47 +0200
committerWladimir J. van der Laan <laanwj@gmail.com>2018-04-07 19:48:39 +0200
commitbecd8dd2ec514f766ee13ac0c01cc74429b966b7 (patch)
tree168d6adabe147493b4d017942c33e0f7db02ef25 /src/util.cpp
parentb2e5fe8b559b2f6561ee8f220e9141e401929f5e (diff)
parentd54874d795a523d7cad5f4a9f4270145e56238f8 (diff)
downloadbitcoin-becd8dd2ec514f766ee13ac0c01cc74429b966b7.tar.xz
Merge #12618: Set SCHED_BATCH priority on the loadblk thread.
d54874d Set SCHED_BATCH priority on the loadblk thread. (Evan Klitzke) Pull request description: Today I came across #10271, and while reading the discussion #6358 was linked to. Linux systems have a `SCHED_BATCH` scheduler priority that is useful for threads like loadblk. You can find the full details at [sched(7)](http://man7.org/linux/man-pages/man7/sched.7.html), but I'll quote the relevant part of the man page below: > ...this policy will cause the scheduler to always assume that the thread is CPU-intensive. Consequently, the scheduler will apply a small scheduling penalty with respect to wakeup behavior, so that this thread is mildly disfavored in scheduling decisions. > > This policy is useful for workloads that are noninteractive, but do not want to lower their nice value, and for workloads that want a deterministic scheduling policy without interactivity causing extra preemptions (between the workload's tasks). I think this change is useful independently of #10271 and irrespective of whether that change is merged. Under normal operation the loadblk thread will just import `mempool.dat`. However, if Bitcoin is started with `-reindex` or `-reindex-chainstate` this thread will use a great deal of CPU while it rebuilds the chainstate database (and the block database in the case of `-reindex`). By setting `SCHED_BATCH` this thread is less likely to interfere with interactive tasks (e.g. the user's web browser, text editor, etc.). I'm leaving the nice value unchanged (which also affects scheduling decisions) because I think that's better set by the user. Likewise I'm not using [ioprio_set(2)](http://man7.org/linux/man-pages/man2/ioprio_set.2.html) because it can cause the thread to become completely I/O starved (and knowledgeable users can use `ionice(1)` anyway). Tree-SHA512: ea8f7d3921ed5708948809da771345cdc33efd7ba3323e9dfec07a25bc21e8612e2676f9c178e2710c7bc437e8c9cafc5e0463613688fea5699b6e8e2fec6cff
Diffstat (limited to 'src/util.cpp')
-rw-r--r--src/util.cpp15
1 files changed, 15 insertions, 0 deletions
diff --git a/src/util.cpp b/src/util.cpp
index 46054f5025..8b36c3e5f7 100644
--- a/src/util.cpp
+++ b/src/util.cpp
@@ -31,6 +31,7 @@
#include <algorithm>
#include <fcntl.h>
+#include <sched.h>
#include <sys/resource.h>
#include <sys/stat.h>
@@ -1039,3 +1040,17 @@ fs::path AbsPathForConfigVal(const fs::path& path, bool net_specific)
{
return fs::absolute(path, GetDataDir(net_specific));
}
+
+int ScheduleBatchPriority(void)
+{
+#ifdef SCHED_BATCH
+ const static sched_param param{.sched_priority = 0};
+ if (int ret = pthread_setschedparam(0, SCHED_BATCH, &param)) {
+ LogPrintf("Failed to pthread_setschedparam: %s\n", strerror(errno));
+ return ret;
+ }
+ return 0;
+#else
+ return 1;
+#endif
+}