[PATCH 3/3] sched: Use hrticks even with >sched_nr_latency tasks

From: Alexander Graf
Date: Wed Aug 26 2020 - 20:44:41 EST


When hrticks are enabled, we configure an hrtimer fire at the exact point
in time when we would like to have a rescheduling event occur.

However, the current code disables that logic when the number of currently
running tasks exceeds sched_nr_latency. sched_nr_latency describes the point
at which CFS resorts to giving each task sched_min_granularity slices.

However, these slices may well be smaller than the HZ tick and we thus may
still want to use hrticks to ensure that we can actually slice the CPU time
at sched_min_granularity.

This patch changes the logic to still enable hrticks if sched_min_granularity
is smaller than the HZ tick would allow us to account with. That way systems
with HZ=1000 will usually resort to the HZ tick while systems at lower HZ values
will keep using hrticks.

Signed-off-by: Alexander Graf <graf@xxxxxxxxxx>
---
kernel/sched/fair.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 66e7aae8b15e..0092bba52edf 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5502,7 +5502,8 @@ static void hrtick_update(struct rq *rq)
if (!hrtick_enabled(rq) || curr->sched_class != &fair_sched_class)
return;

- if (cfs_rq_of(&curr->se)->nr_running < sched_nr_latency)
+ if ((cfs_rq_of(&curr->se)->nr_running < sched_nr_latency) ||
+ (sysctl_sched_min_granularity < (HZ * 1000000)))
hrtick_start_fair(rq, curr);
}
#else /* !CONFIG_SCHED_HRTICK */
--
2.26.2




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879