All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qais Yousef <qais.yousef@arm.com>
To: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Pavan Kondeti <pkondeti@codeaurora.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	linux-kernel@vger.kernel.org, Qais Yousef <qais.yousef@arm.com>
Subject: [PATCH 0/3] RT Capacity Awareness Improvements
Date: Fri, 14 Feb 2020 16:39:46 +0000	[thread overview]
Message-ID: <20200214163949.27850-1-qais.yousef@arm.com> (raw)

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.

https://lore.kernel.org/lkml/20200203111451.0d1da58f@oasis.local.home/

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
		  expected

[1] https://gist.github.com/qais-yousef/bb99bdd912628489408a5edae33f85e1

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(-)

-- 
2.17.1


             reply	other threads:[~2020-02-14 16:40 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-14 16:39 Qais Yousef [this message]
2020-02-14 16:39 ` [PATCH 1/3] sched/rt: cpupri_find: implement fallback mechanism for !fit case Qais Yousef
2020-02-17 17:07   ` Valentin Schneider
2020-02-17 23:34     ` Qais Yousef
2020-02-18 10:01       ` Valentin Schneider
2020-02-17 19:09   ` Dietmar Eggemann
2020-02-17 23:45     ` Qais Yousef
2020-02-18  9:53       ` Dietmar Eggemann
2020-02-18 17:28         ` Qais Yousef
2020-02-18 16:46       ` Steven Rostedt
2020-02-18 17:27         ` Qais Yousef
2020-02-18 18:03           ` Steven Rostedt
2020-02-18 18:52             ` Qais Yousef
2020-02-14 16:39 ` [PATCH 2/3] sched/rt: allow pulling unfitting task Qais Yousef
2020-02-17  9:10   ` Pavan Kondeti
2020-02-17 11:20     ` Qais Yousef
2020-02-19 13:43     ` Qais Yousef
2020-02-21  8:07       ` Pavan Kondeti
2020-02-21 11:08         ` Qais Yousef
2020-02-14 16:39 ` [PATCH 3/3] sched/rt: fix pushing unfit tasks to a better CPU Qais Yousef
2020-02-17  9:23   ` Pavan Kondeti
2020-02-17 13:53     ` Qais Yousef
2020-02-18  4:16       ` Pavan Kondeti
2020-02-18 17:47         ` Qais Yousef
2020-02-19  2:46           ` Pavan Kondeti
2020-02-19 10:46             ` Qais Yousef
2020-02-19 14:02       ` Qais Yousef
2020-02-21  8:15         ` Pavan Kondeti
2020-02-21 11:12           ` Qais Yousef

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200214163949.27850-1-qais.yousef@arm.com \
    --to=qais.yousef@arm.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pkondeti@codeaurora.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.