From: Joel Fernandes <joel@joelfernandes.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Patrick Bellasi <patrick.bellasi@arm.com>,
Subhra Mazumdar <subhra.mazumdar@oracle.com>,
linux-kernel@vger.kernel.org, mingo@redhat.com,
tglx@linutronix.de, steven.sistare@oracle.com,
dhaval.giani@oracle.com, daniel.lezcano@linaro.org,
vincent.guittot@linaro.org, viresh.kumar@linaro.org,
tim.c.chen@linux.intel.com, mgorman@techsingularity.net,
parth@linux.ibm.com
Subject: Re: [RFC PATCH 1/9] sched,cgroup: Add interface for latency-nice
Date: Wed, 15 Apr 2020 20:02:35 -0400 [thread overview]
Message-ID: <20200416000235.GA211099@google.com> (raw)
In-Reply-To: <20190905114725.ehi5ea6qg3rychlz@e107158-lin.cambridge.arm.com>
On Thu, Sep 05, 2019 at 12:47:26PM +0100, Qais Yousef wrote:
> On 09/05/19 13:30, Peter Zijlstra wrote:
> > On Thu, Sep 05, 2019 at 12:13:47PM +0100, Qais Yousef wrote:
> > > On 09/05/19 12:46, Peter Zijlstra wrote:
> >
> > > > This is important because we want to be able to bias towards less
> > > > importance to (tail) latency as well as more importantance to (tail)
> > > > latency.
> > > >
> > > > Specifically, Oracle wants to sacrifice (some) latency for throughput.
> > > > Facebook OTOH seems to want to sacrifice (some) throughput for latency.
> > >
> > > Another use case I'm considering is using latency-nice to prefer an idle CPU if
> > > latency-nice is set otherwise go for the most energy efficient CPU.
> > >
> > > Ie: sacrifice (some) energy for latency.
> > >
> > > The way I see interpreting latency-nice here as a binary switch. But
> > > maybe we can use the range to select what (some) energy to sacrifice
> > > mean here. Hmmm.
> >
> > It cannot be binary, per definition is must be ternary, that is, <0, ==0
> > and >0 (or middle value if you're of that persuasion).
>
> I meant I want to use it as a binary.
>
> >
> > In your case, I'm thinking you mean >0, we want to lower the latency.
>
> Yes. As long as there's an easy way to say: does this task care about latency
> or not I'm good.
Qais, Peter, all,
For ChromeOS (my team), we are planning to use the upstream uclamp mechanism
instead of the out-of-tree schedtune mechanism to provide EAS with the
latency-sensitivity (binary/ternary) hint. ChromeOS is thankfully quite a bit
upstream focussed :)
However, uclamp is missing an attribute to provide this biasing to EAS as we
know.
What was the consensus on adding a per-task attribute to uclamp for providing
this? Happy to collaborate on this front.
thanks,
- Joel
> > Anyway; there were a number of things mentioned at OSPM that we could
> > tie into this thing and finding sensible mappings is going to be a bit
> > of trial and error I suppose.
> >
> > But as patrick said; we're very much exporting a BIAS knob, not a set of
> > behaviours.
>
> Agreed. I just wanted to say that the way this range is going to be
> interpreted will differ from path to path and we need to consider that in the
> final mapping. Especially from the final user's perspective of what setting
> this value ultimately means to them.
>
> --
> Qais Yousef
next prev parent reply other threads:[~2020-04-16 0:02 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-30 17:49 [RFC PATCH 0/9] Task latency-nice subhra mazumdar
2019-08-30 17:49 ` [RFC PATCH 1/9] sched,cgroup: Add interface for latency-nice subhra mazumdar
2019-09-04 17:32 ` Tim Chen
2019-09-05 6:15 ` Parth Shah
2019-09-05 10:11 ` Patrick Bellasi
2019-09-06 12:22 ` Parth Shah
2019-09-05 8:31 ` Peter Zijlstra
2019-09-05 9:45 ` Patrick Bellasi
2019-09-05 10:46 ` Peter Zijlstra
2019-09-05 11:13 ` Qais Yousef
2019-09-05 11:30 ` Peter Zijlstra
2019-09-05 11:40 ` Patrick Bellasi
2019-09-05 11:48 ` Peter Zijlstra
2019-09-05 13:32 ` Qais Yousef
2019-09-05 11:47 ` Qais Yousef
2020-04-16 0:02 ` Joel Fernandes [this message]
2020-04-16 17:23 ` Dietmar Eggemann
2020-04-18 16:01 ` Joel Fernandes
2020-04-20 11:26 ` Parth Shah
2020-04-20 19:14 ` Joel Fernandes
2020-04-20 11:47 ` Qais Yousef
2020-04-20 19:10 ` Joel Fernandes
2019-09-05 11:30 ` Patrick Bellasi
2019-09-05 11:47 ` Peter Zijlstra
2019-09-05 11:18 ` Patrick Bellasi
2019-09-05 11:40 ` Peter Zijlstra
2019-09-05 11:46 ` Patrick Bellasi
2019-09-05 11:46 ` Valentin Schneider
2019-09-05 13:07 ` Patrick Bellasi
2019-09-05 14:48 ` Valentin Schneider
2019-09-06 12:45 ` Parth Shah
2019-09-06 14:13 ` Valentin Schneider
2019-09-06 14:32 ` Vincent Guittot
2019-09-06 17:10 ` Parth Shah
2019-09-06 22:50 ` Valentin Schneider
2019-09-06 12:31 ` Parth Shah
2019-09-05 10:05 ` Patrick Bellasi
2019-09-05 10:48 ` Peter Zijlstra
2019-08-30 17:49 ` [RFC PATCH 2/9] sched: add search limit as per latency-nice subhra mazumdar
2019-09-05 6:22 ` Parth Shah
2019-08-30 17:49 ` [RFC PATCH 3/9] sched: add sched feature to disable idle core search subhra mazumdar
2019-09-05 10:17 ` Patrick Bellasi
2019-09-05 22:02 ` Subhra Mazumdar
2019-08-30 17:49 ` [RFC PATCH 4/9] sched: SIS_CORE " subhra mazumdar
2019-09-05 10:19 ` Patrick Bellasi
2019-08-30 17:49 ` [RFC PATCH 5/9] sched: Define macro for number of CPUs in core subhra mazumdar
2019-08-30 17:49 ` [RFC PATCH 6/9] x86/smpboot: Optimize cpumask_weight_sibling macro for x86 subhra mazumdar
2019-08-30 17:49 ` [RFC PATCH 7/9] sched: search SMT before LLC domain subhra mazumdar
2019-09-05 9:31 ` Peter Zijlstra
2019-09-05 20:40 ` Subhra Mazumdar
2019-08-30 17:49 ` [RFC PATCH 8/9] sched: introduce per-cpu var next_cpu to track search limit subhra mazumdar
2019-08-30 17:49 ` [RFC PATCH 9/9] sched: rotate the cpu search window for better spread subhra mazumdar
2019-09-05 6:37 ` Parth Shah
2019-09-05 5:55 ` [RFC PATCH 0/9] Task latency-nice Parth Shah
2019-09-05 10:31 ` Patrick Bellasi
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=20200416000235.GA211099@google.com \
--to=joel@joelfernandes.org \
--cc=daniel.lezcano@linaro.org \
--cc=dhaval.giani@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=parth@linux.ibm.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=steven.sistare@oracle.com \
--cc=subhra.mazumdar@oracle.com \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@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).