From: Qais Yousef <qais.yousef@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Juri Lelli <juri.lelli@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] sched: rt: Make RT capacity aware
Date: Tue, 29 Oct 2019 12:46:30 +0000 [thread overview]
Message-ID: <20191029124630.ivfbpenue3fw33qt@e107158-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAKfTPtD7e-dXhZ3mG36igArt=0f-mNc52vaJ1bb-jv5zB9bkgg@mail.gmail.com>
On 10/29/19 13:20, Vincent Guittot wrote:
> > > Making big cores the default CPUs for all RT tasks is not a minor
> > > change and IMO locality should stay the default behavior when there is
> > > no uclamp constraint
> >
> > How this is affecting locality? The task will always go to the big core, so it
> > should be local.
>
> local with the waker
> You will force rt task to run on big cluster although waker, data and
> interrupts can be on little one.
> So making big core as default is far from always being the best choice
This is loaded with assumptions IMO. AFAICT we don't know what's the best
choice.
First, the value of uclamp.min is outside of the scope of this patch. Unless
what you're saying is that when uclamp.min is 1024 then we should NOT choose a
big cpu then there's no disagreement about what this patch do. If that's what
you're objecting to please be more specific about how do you see this working
instead.
If your objection is purely based on the choice of uclamp.min then while
I agree that on modern systems the little cores are good enough for the
majority of RT tasks in average Android systems. But I don't feel confident to
reach this conclusion on low end systems where the little core doesn't have
enough grunt in many cases. So I see the current default is adequate and the
responsibility of further tweaking lies within the hands of the system admin.
--
Qais Yousef
next prev parent reply other threads:[~2019-10-29 12:46 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-09 10:46 [PATCH v2] sched: rt: Make RT capacity aware 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 [this message]
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
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=20191029124630.ivfbpenue3fw33qt@e107158-lin.cambridge.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=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 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).