linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Pavan Kondeti <pkondeti@codeaurora.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] sched: rt: Make RT capacity aware
Date: Mon, 3 Feb 2020 11:14:51 -0500	[thread overview]
Message-ID: <20200203111451.0d1da58f@oasis.local.home> (raw)
In-Reply-To: <20200203142712.a7yvlyo2y3le5cpn@e107158-lin>

On Mon, 3 Feb 2020 14:27:14 +0000
Qais Yousef <qais.yousef@arm.com> wrote:

> I don't see one right answer here. The current mechanism could certainly do
> better; but it's not clear what better means without delving into system
> specific details. I am open to any suggestions to improve it.

The way I see this is that if there's no big cores available but little
cores are, and the RT task has those cores in its affinity mask then
the task most definitely should consider moving to the little core. The
cpu_find() should return them!

But, what we can do is to mark the little core that's running an RT
task on a it that prefers bigger cores, as "rt-overloaded".  This will
add this core into the being looked at when another core schedules out
an RT task. When that happens, the RT task on the little core will get
pulled back to the big core.

Here's what I propose.

1. Scheduling of an RT task that wants big cores, but has little cores
in its affinity.

2. Calls cpu_find() which will look to place it first on a big core, if
there's a core that is running a task that is lower priority than
itself.

3. If all the big cores have RT tasks it can not preempt, look to find
a little core.

4. If a little core is returned, and we schedule an RT task that
prefers big cores on it, we mark it overloaded.

5. An RT task on a big core schedules out. Start looking at the RT
overloaded run queues.

6. See that there's an RT task on the little core, and migrate it over.


Note, this will require a bit more logic as the overloaded code wasn't
designed for migration of running tasks, but that could be added.

-- Steve

  reply	other threads:[~2020-02-03 16:15 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09 10:46 Qais Yousef
2019-10-23 12:34 ` Qais Yousef
2019-10-28 14:37 ` Peter Zijlstra
2019-10-28 18:01   ` Steven Rostedt
2019-10-28 20:50     ` Peter Zijlstra
2019-12-20 16:01       ` Qais Yousef
2019-12-20 17:18         ` Peter Zijlstra
2019-12-20 17:36           ` Qais Yousef
2019-11-07  9:15     ` Qais Yousef
2019-11-18 15:43     ` Qais Yousef
2019-11-18 15:53       ` Steven Rostedt
2019-11-18 16:12         ` Qais Yousef
2019-10-29  8:13 ` Vincent Guittot
2019-10-29 11:02   ` Qais Yousef
2019-10-29 11:17     ` Vincent Guittot
2019-10-29 11:48       ` Qais Yousef
2019-10-29 12:20         ` Vincent Guittot
2019-10-29 12:46           ` Qais Yousef
2019-10-29 12:54             ` Vincent Guittot
2019-10-29 13:02               ` Peter Zijlstra
2019-10-29 20:36               ` Patrick Bellasi
2019-10-30  8:04                 ` Vincent Guittot
2019-10-30  9:26                   ` Qais Yousef
2019-10-30 12:11                   ` Quentin Perret
2019-10-30 11:57 ` Dietmar Eggemann
2019-10-30 17:43   ` Qais Yousef
2019-11-28 13:59     ` Dietmar Eggemann
2019-11-25 21:36 ` Steven Rostedt
2019-11-26  9:39   ` Qais Yousef
2019-12-25 10:38 ` [tip: sched/core] sched/rt: Make RT capacity-aware tip-bot2 for Qais Yousef
2020-01-31 10:06 ` [PATCH v2] sched: rt: Make RT capacity aware Pavan Kondeti
2020-01-31 15:34   ` Qais Yousef
     [not found]     ` <CAEU1=PnYryM26F-tNAT0JVUoFcygRgE374JiBeJPQeTEoZpANg@mail.gmail.com>
2020-02-03  5:32       ` Pavan Kondeti
2020-02-03 14:57         ` Qais Yousef
2020-02-03 14:27       ` Qais Yousef
2020-02-03 16:14         ` Steven Rostedt [this message]
2020-02-03 17:15           ` Valentin Schneider
2020-02-03 17:17           ` Qais Yousef
2020-02-03 18:12             ` Steven Rostedt
2020-02-03 19:03               ` Qais Yousef
2020-02-04 17:23                 ` Dietmar Eggemann
2020-02-05 14:48                   ` 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=20200203111451.0d1da58f@oasis.local.home \
    --to=rostedt@goodmis.org \
    --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=qais.yousef@arm.com \
    --cc=vincent.guittot@linaro.org \
    --subject='Re: [PATCH v2] sched: rt: Make RT capacity aware' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).