|
|
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] sched/eevdf: Improve scheduling latency of short slice task
Date:  Mon, 15 Jun 2026 17:19:51 +0200
Message-ID:  <20260615151957.299839-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 testing 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 %) |    56 (+30 %)
99th Percentile               93 |    92 (+ 1 %) |    60 (+35 %)
99.9th Percentile            184 |   129 (+30 %) |    67 (+64 %)
Maximum                     7526 |  2605 (+65 %) |  2647 (+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               61 |    65 (- 7 %) |   440 (-621 %)
99th Percentile             8453 |  2324 (+73 %) |  3167 (+ 63 %)
99.9th Percentile          14053 |  5041 (+64 %) |  5290 (+ 62 %)
Maximum                    20924 |  7849 (+62 %) |  8727 (+ 58 %)

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 %) |  1237 (-1863 %)
99th Percentile               76 |    81 (- 7 %) |  4575 (-5920 %)
99.9th Percentile           2827 |  1230 (+56 %) |  8312 (- 194 %)
Maximum                    15795 |  5252 (+67 %) | 14519 (+   8 %)

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 | 43 +++++++++++++++++++++++++------------------
 1 file changed, 25 insertions(+), 18 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