@@ -844,6 +844,40 @@ config CACULE_SCHED
844
844
845
845
If unsure, say Y here.
846
846
847
+ config CACULE_RDB
848
+ bool "RDB (Response Driven Balancer)"
849
+ default y
850
+ depends on CACULE_SCHED
851
+ help
852
+ This is an experimental load balancer for CacULE. It is a lightweight
853
+ load balancer which is a replacement of CFS load balancer. It migrates
854
+ tasks based on their interactivity scores.
855
+
856
+ If unsure, say Y here.
857
+
858
+ config RDB_INTERVAL
859
+ int "RDB load balancer interval"
860
+ default 19
861
+ depends on CACULE_RDB
862
+ help
863
+ This is an interval to control load balance time period.
864
+ The trigger_load_balance runs in every tick. For High HZ values, the
865
+ load balance could be overwhelming. RDB load balance includes rq locking
866
+ which can reduce the performance. The balance interval can help to avoid
867
+ running load balance on every tick. For example, RDB_INTERVAL=3 will
868
+ only run load balance every 3ms. Setting RDB_INTERVAL depends on HZ.
869
+ If you want load balancer run every 2ms while HZ=500 then it is not
870
+ needed and better to set RDB_INTERVAL=0 since 500HZ already (1000ms
871
+ / 500HZ = 2ms). However, if you have 1000HZ and want to avoid load
872
+ balancer from running every 1ms, you could set RDB_INTERVAL=4ms for
873
+ example to make load balancer run every 4ms. Less RDB_INTERVAL values
874
+ (or 0 to disable) could make sure tasks are balanced ASAP, but with
875
+ the cost of locking/blocking time. High RDB_INTERVAL values can relax
876
+ balancing locking but with the cost of imbalanced workload for that
877
+ period of time (i.e. if RDB_INTERVAL=100ms) there will be no balancing
878
+ for 100ms (except for newidle_balance which is not effected by RDB_INTERVAL).
879
+
880
+ If in doubt, use the default value.
847
881
848
882
#
849
883
# For architectures that want to enable the support for NUMA-affine scheduler
0 commit comments