Set the rebalance thread's scheduling class to BATCH, which means it
could experience a higher scheduling latency. However, it reduces
preemption events of running threads.

And while the rebalance thread is ually not compute bound, it does
cause a considerable amount of I/O. By increasing its nice level from
0 to 19 we also implicitly reduce the thread's best-effort I/O
scheduling class level from 4 to 7. Therefore, the rebalance thread's
I/O operations will be deprioritized over standard I/O operations.

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 4adc74cd3f70..b26c68007c5a 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>
 
 /* bch_extent_rebalance: */
@@ -662,6 +663,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


Reply via email to