From: Patrick Bellasi <patrick.bellasi@arm.com>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
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: Thu, 05 Sep 2019 12:30:52 +0100 [thread overview]
Message-ID: <87h85r2d5f.fsf@arm.com> (raw)
In-Reply-To: <20190905111346.2w6kuqrdvaqvgilu@e107158-lin.cambridge.arm.com>
On Thu, Sep 05, 2019 at 12:13:47 +0100, Qais Yousef wrote...
> On 09/05/19 12:46, Peter Zijlstra wrote:
>> On Thu, Sep 05, 2019 at 10:45:27AM +0100, Patrick Bellasi wrote:
>>
>> > > From just reading the above, I would expect it to have the range
>> > > [-20,19] just like normal nice. Apparently this is not so.
>> >
>> > Regarding the range for the latency-nice values, I guess we have two
>> > options:
>> >
>> > - [-20..19], which makes it similar to priorities
>> > downside: we quite likely end up with a kernel space representation
>> > which does not match the user-space one, e.g. look at
>> > task_struct::prio.
>> >
>> > - [0..1024], which makes it more similar to a "percentage"
>> >
>> > Being latency-nice a new concept, we are not constrained by POSIX and
>> > IMHO the [0..1024] scale is a better fit.
>> >
>> > That will translate into:
>> >
>> > latency-nice=0 : default (current mainline) behaviour, all "biasing"
>> > policies are disabled and we wakeup up as fast as possible
>> >
>> > latency-nice=1024 : maximum niceness, where for example we can imaging
>> > to turn switch a CFS task to be SCHED_IDLE?
>>
>> There's a few things wrong there; I really feel that if we call it nice,
>> it should be like nice. Otherwise we should call it latency-bias and not
>> have the association with nice to confuse people.
>>
>> Secondly; the default should be in the middle of the range. Naturally
>> this would be a signed range like nice [-(x+1),x] for some x. but if you
>> want [0,1024], then the default really should be 512, but personally I
>> like 0 better as a default, in which case we need negative numbers.
>>
>> 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.
I see this concept possibly evolving into something more then just a
binary switch. Not yet convinced if it make sense and/or it's possible
but, in principle, I was thinking about these possible usages for CFS
tasks:
- dynamically tune the policy of a task among SCHED_{OTHER,BATCH,IDLE}
depending on crossing certain pre-configured threshold of latency
niceness.
- dynamically bias the vruntime updates we do in place_entity()
depending on the actual latency niceness of a task.
- bias the decisions we take in check_preempt_tick() still depending
on a relative comparison of the current and wakeup task latency
niceness values.
--
#include <best/regards.h>
Patrick Bellasi
next prev parent reply other threads:[~2019-09-05 11:30 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
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 [this message]
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=87h85r2d5f.fsf@arm.com \
--to=patrick.bellasi@arm.com \
--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=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).