From: chris hyser <chris.hyser@oracle.com>
To: Parth Shah <parth@linux.ibm.com>, linux-kernel@vger.kernel.org
Cc: peterz@infradead.org, mingo@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
qais.yousef@arm.com, pkondeti@codeaurora.org,
patrick.bellasi@matbug.net, valentin.schneider@arm.com,
David.Laight@ACULAB.COM, pjt@google.com, pavel@ucw.cz,
tj@kernel.org, dhaval.giani@oracle.com, qperret@google.com,
tim.c.chen@linux.intel.com
Subject: Re: [PATCH v5 0/4] Introduce per-task latency_nice for scheduler hints
Date: Fri, 6 Mar 2020 11:36:10 -0500 [thread overview]
Message-ID: <2bf111d3-bc0a-80ef-29e4-b8487701e428@oracle.com> (raw)
In-Reply-To: <20200228090755.22829-1-parth@linux.ibm.com>
On 2/28/20 4:07 AM, Parth Shah wrote:
> This is the 5th revision of the patch set to introduce latency_nice as a
> per task attribute.
>
> The previous version can be found at:
> v1: https://lkml.org/lkml/2019/11/25/151
> v2: https://lkml.org/lkml/2019/12/8/10
> v3: https://lkml.org/lkml/2020/1/16/319
> v4: https://lkml.org/lkml/2020/2/24/216
>
> Changes in this revision are:
> v4->v5:
> - Added debugging prints in /proc/<pid>/sched for latency_nice ( based on
> suggestion from Pavan Kondeti )
> - Initialized init_task with latency_nice = 0
> - Collected review tag and added few minor fixes.
> v3->v4:
> - Based on Chris's comment, added security check to refrain non-root user
> set lower value than the current latency_nice values.
> v2 -> v3:
> - This series changes the longer attribute name to "latency_nice" as per
> the comment from Dietmar Eggemann https://lkml.org/lkml/2019/12/5/394
> v1 -> v2:
> - Addressed comments from Qais Yousef
> - As per suggestion from Dietmar, moved content from newly created
> include/linux/sched/latency_tolerance.h to kernel/sched/sched.h
> - Extend sched_setattr() to support latency_tolerance in tools headers UAPI
>
>
> Introduction:
> ==============
> This patch series introduces a new per-task attribute latency_nice to
> provide the scheduler hints about the latency requirements of the task [1].
>
> Latency_nice is a ranged attribute of a task with the value ranging
> from [-20, 19] both inclusive which makes it align with the task nice
> value.
>
> The value should provide scheduler hints about the relative latency
> requirements of tasks, meaning the task with "latency_nice = -20"
> should have lower latency requirements than compared to those tasks with
> higher values. Similarly a task with "latency_nice = 19" can have higher
> latency and hence such tasks may not care much about latency.
>
> The default value is set to 0. The usecases discussed below can use this
> range of [-20, 19] for latency_nice for the specific purpose. This
> patch does not implement any use cases for such attribute so that any
> change in naming or range does not affect much to the other (future)
> patches using this. The actual use of latency_nice during task wakeup
> and load-balancing is yet to be coded for each of those usecases.
>
> As per my view, this defined attribute can be used in following ways for a
> some of the usecases:
> 1 Reduce search scan time for select_idle_cpu():
> - Reduce search scans for finding idle CPU for a waking task with lower
> latency_nice values.
>
> 2 TurboSched:
> - Classify the tasks with higher latency_nice values as a small
> background task given that its historic utilization is very low, for
> which the scheduler can search for more number of cores to do task
> packing. A task with a latency_nice >= some_threshold (e.g, == 19)
> and util <= 12.5% can be background tasks.
>
> 3 Optimize AVX512 based workload:
> - Bias scheduler to not put a task having (latency_nice == -20) on a
> core occupying AVX512 based workload.
>
>
> Series Organization:
> ====================
> - Patch 1-3: Add support for latency_nice attr in the task struct using
> sched_{set,get}attr syscall
> - Patch 4 : Add permission checks for setting the value.
>
>
> The patch series can be applied on tip/sched/core at the
> commit a0f03b617c3b ("sched/numa: Stop an exhastive search if a reasonable swap candidate or idle CPU is found")
>
>
> References:
> ============
> [1]. Usecases for the per-task latency-nice attribute,
> https://lkml.org/lkml/2019/9/30/215
> [2]. Task Latency-nice, "Subhra Mazumdar",
> https://lkml.org/lkml/2019/8/30/829
> [3]. Introduce per-task latency_tolerance for scheduler hints,
> https://lkml.org/lkml/2019/12/8/10
>
>
>
> Parth Shah (4):
> sched: Introduce latency-nice as a per-task attribute
> sched/core: Propagate parent task's latency requirements to the child
> task
> sched: Allow sched_{get,set}attr to change latency_nice of the task
> sched/core: Add permission checks for setting the latency_nice value
>
> include/linux/sched.h | 1 +
> include/uapi/linux/sched.h | 4 +++-
> include/uapi/linux/sched/types.h | 19 +++++++++++++++++++
> init/init_task.c | 1 +
> kernel/sched/core.c | 26 ++++++++++++++++++++++++++
> kernel/sched/debug.c | 1 +
> kernel/sched/sched.h | 18 ++++++++++++++++++
> tools/include/uapi/linux/sched.h | 4 +++-
> 8 files changed, 72 insertions(+), 2 deletions(-)
I've now had a chance to test and play with this a fair amount. It looks good, meets the need. Thanks Parth.
-chrish
prev parent reply other threads:[~2020-03-06 16:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-28 9:07 [PATCH v5 0/4] Introduce per-task latency_nice for scheduler hints Parth Shah
2020-02-28 9:07 ` [PATCH v5 1/4] sched: Introduce latency-nice as a per-task attribute Parth Shah
2020-02-28 9:07 ` [PATCH v5 2/4] sched/core: Propagate parent task's latency requirements to the child task Parth Shah
2020-02-28 9:07 ` [PATCH v5 3/4] sched: Allow sched_{get,set}attr to change latency_nice of the task Parth Shah
2020-05-11 11:13 ` Dietmar Eggemann
2020-05-13 9:41 ` Parth Shah
2020-05-13 11:14 ` Parth Shah
2020-02-28 9:07 ` [PATCH v5 4/4] sched/core: Add permission checks for setting the latency_nice value Parth Shah
2020-03-06 16:36 ` chris hyser [this message]
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=2bf111d3-bc0a-80ef-29e4-b8487701e428@oracle.com \
--to=chris.hyser@oracle.com \
--cc=David.Laight@ACULAB.COM \
--cc=dhaval.giani@oracle.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=parth@linux.ibm.com \
--cc=patrick.bellasi@matbug.net \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=pkondeti@codeaurora.org \
--cc=qais.yousef@arm.com \
--cc=qperret@google.com \
--cc=tim.c.chen@linux.intel.com \
--cc=tj@kernel.org \
--cc=valentin.schneider@arm.com \
--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).