While the rebalance thread is isually not compute bound, it does cause a considerable amount of I/O. Since "reducing" the nice level from 0 to 19, also implicitly reduces the threads best-effort I/O scheduling class level from 4 to 7, the reblance thread's I/O will be depriotized over normal I/O.
Furthermore, we set the rebalance thread's scheduling class to BATCH, which means that it will potentially receive a higher scheduling latency. Making room for threads that need a low schedulinglatency (e.g., interactive onces). Signed-off-by: Florian Schmaus <[email protected]> --- fs/bcachefs/rebalance.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/bcachefs/rebalance.c b/fs/bcachefs/rebalance.c index cd6647374353..87e4f507af80 100644 --- a/fs/bcachefs/rebalance.c +++ b/fs/bcachefs/rebalance.c @@ -22,6 +22,7 @@ #include <linux/freezer.h> #include <linux/kthread.h> +#include <linux/sched.h> #include <linux/sched/cputime.h> #define REBALANCE_WORK_SCAN_OFFSET (U64_MAX - 1) @@ -478,6 +479,8 @@ int bch2_rebalance_start(struct bch_fs *c) if (ret) return ret; + sched_set_batch(p, 19); + get_task_struct(p); rcu_assign_pointer(c->rebalance.thread, p); wake_up_process(p); -- 2.45.2
