[lkml]   [2020]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH 0/3] RT Capacity Awareness Improvements
Pavan has pointed out an oversight in the first implementation where we don't
fallback to another unfitting CPU if we are already running on unfitting one.

This also stirred discussion around handling downmigration from fitting to
unfitting CPU.

Patch 1 adds the missing fallback when a fitting CPU wasn't found, reported
by Pavan.

Patch 2 allows downmigration in the pull case and marks the CPU as overloaded
as suggested by Steve.

Patch 3 fixes the condition in select_task_rq_rt() in case the new_cpu and the
task priorities are the *same*.

The series is based on Linus/master v5.6-rc1.

I ran the following test cases, the results of which can be found in [1]
Each test was run 3 times to demonstrate repeatability of the result.

The tests were ran on Juno-r2, which has 6 CPUs. CPUs [0, 3-5] are Littles and
CPUs [1-2] are Bigs.

By default RT tasks are boosted to max capacity, so no work was done to modify
that. ie: rt_task->uclamp_min = 1024 for all running tests.

1. 6 RT Tasks
* 2 Tasks always end up on the big cores
* The rest end up on the little cores with migration among them
happening (it didn't before)
2. 2 RT Tasks
* We can see they always end up on the 2 big cores
3. 4 RT Tasks
* Results similar to 1
4. 4 RT Tasks affined to little cores
* The tasks run on the little cores with some migration as


Qais Yousef (3):
sched/rt: cpupri_find: implement fallback mechanism for !fit case
sched/rt: allow pulling unfitting task
sched/rt: fix pushing unfit tasks to a better CPU

kernel/sched/cpupri.c | 157 +++++++++++++++++++++++++++---------------
kernel/sched/rt.c | 50 ++++++++++----
2 files changed, 139 insertions(+), 68 deletions(-)


 \ /
  Last update: 2020-02-14 17:40    [W:0.127 / U:1.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site