|
|
Log in / Subscribe / Register

sched/eevdf: Improve scheduling latency of short slice task

From:  Vincent Guittot <vincent.guittot-AT-linaro.org>
To:  mingo-AT-redhat.com, peterz-AT-infradead.org, juri.lelli-AT-redhat.com, dietmar.eggemann-AT-arm.com, rostedt-AT-goodmis.org, bsegall-AT-google.com, mgorman-AT-suse.de, vschneid-AT-redhat.com, kprateek.nayak-AT-amd.com, linux-kernel-AT-vger.kernel.org, qyousef-AT-layalina.io
Subject:  [PATCH 0/6 v3] sched/eevdf: Improve scheduling latency of short slice task
Date:  Wed, 24 Jun 2026 17:12:23 +0200
Message-ID:  <20260624151229.1710703-1-vincent.guittot@linaro.org>
Cc:  Vincent Guittot <vincent.guittot-AT-linaro.org>
Archive-link:  Article

This series continues to improve the scheduling latency of tasks with
shorter slice duration by mainly canceling, updating or minimizing the
protection of the running tasks when appropriate.

Benchmarks, like hackbench, haven't seen any noticeable performance
differences with this patchset (The default 2.8ms slice has been used for
testing performance regressions)

Several use cases has been used to test the scheduling latency of short
slice tasks:
- cyclictest with a 3777us period and a 8ms slice alone
- cyclictest with a 3777us period and a 8ms slice. 2xNR_CPUS rt-app
  tasks that run (8177us) and sleep (17777us) with a 16ms slice.
- cyclictest with a 3777us period and a 8ms slice. Hackbench with
  1 group using thread and pipe and a 16ms slice.

NB: periods and run duration have been chosen to minimize alignment
with tick or other periodic activities.

scheduling latency (us) for cyclictest
                   tip/sched/core| this patchset | tip/sched/core
slice                 8ms        |  8ms          |  2.8ms
90th Percentile               80 |    80 (  0 %) |    79 (+  1 %)
99th Percentile               92 |    93 (- 1 %) |    93 (-  1 %)
99.9th Percentile            238 |   180 (+24 %) |  1551 (-552 %)
Maximum                     3177 |  2261 (+29 %) |  4771 (+ 65 %)

scheduling latency (us) for cyclictest and rt-app 
                   tip/sched/core| this patchset | tip/sched/core
slice                 8ms / 16ms |  8ms  / 16 ms |  2.8ms / 2.8ms
90th Percentile               59 |    67 (-14 %) |   358 (-507 %)
99th Percentile            10414 |  2454 (+77 %) |  3222 (+ 69 %)
99.9th Percentile          16547 |  5542 (+67 %) |  5512 (+ 67 %)
Maximum                    24298 |  8526 (+65 %) |  8650 (+ 64 %)

scheduling latency (us) for cyclictest and hackbench 
                   tip/sched/core| this patchset | tip/sched/core
slice                 8ms / 16ms |  8ms  / 16 ms |  2.8ms / 2.8ms
90th Percentile               63 |    63 (  0 %) |  1331 (-2013 %)
99th Percentile               76 |    80 (- 5 %) |  4685 (-6064 %)
99.9th Percentile           3321 |  1152 (+65 %) |  8741 (- 163 %)
Maximum                    17199 | 10432 (+39 %) | 24309 (-  41 %)

Since v2:
- Remove avg_vruntime() in set_protect_slice()
- Make sure to update curr for sched idle and batch tasks
- Use a new eligible_vruntime() function instead of avg_runtime() when a
 short slice task is enqueued but not the next one to run.

Since v1:
- Use the correct min_vruntime() instead of min()

Vincent Guittot (6):
  sched/fair: Set next buddy for preempt short
  sched/eevdf: Take into account current's lag when updating slice
    protection
  sched/eevdf: Update slice protection even when resched is already set
  sched/eevdf: Cancel slice protection if short slice task is eligible
  sched/eevdf: Always update slice protection
  sched/eevdf: Speedup short slice task scheduling

 kernel/sched/fair.c | 92 +++++++++++++++++++++++++++++++++++----------
 1 file changed, 72 insertions(+), 20 deletions(-)

-- 
2.43.0




Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds