lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Sun,  8 Dec 2019 11:34:07 +0530
From:   Parth Shah <parth@...ux.ibm.com>
To:     linux-kernel@...r.kernel.org
Cc:     peterz@...radead.org, mingo@...hat.com, vincent.guittot@...aro.org,
        patrick.bellasi@...bug.net, valentin.schneider@....com,
        qais.yousef@....com, pavel@....cz, dhaval.giani@...cle.com,
        qperret@...rret.net, David.Laight@...LAB.COM, pjt@...gle.com,
        tj@...nel.org, dietmar.eggemann@....com
Subject: [PATCH v2 0/3] Introduce per-task latency_tolerance for scheduler hints

This is the 2nd revision of the patch set to introduce latency_tolerance as
a per task attribute.

The previous version can be found at:
v1: https://lkml.org/lkml/2019/11/25/151

Changes in this revision are:
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


This patch series introduces a new per-task attribute latency_tolerance to
provide the scheduler hints about the latency requirements of the task [1].

Latency_tolerance 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_tolerance = -20"
should have lower latency than compared to those tasks with higher values.
Similarly a task with "latency_tolerance = 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_tolerance 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_tolerance 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_tolerance values.

2 TurboSched:
- Classify the tasks with higher latency_tolerance 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_tolerance >= some_threshold (e.g, >= +18)
  and util <= 12.5% can be background tasks.

3 Optimize AVX512 based workload:
- Bias scheduler to not put a task having (latency_tolerance == -20) on a
  core occupying AVX512 based workload.

Series Organization:
====================
- Patch 1: Add new attribute latency_tolerance to task_struct.
- Patch 2: Clone parent task's attribute to the child task on fork
- Patch 3: Add support for sched_{set,get}attr syscall to modify
  	     latency_tolerance of the task

Patch 1 is kept separate for review purposes and may be merged to patch 3.

Though, the comment https://lkml.org/lkml/2019/12/6/276 from Dietmar
suggests using latency_nice as the shorter name instead of currently the
proposed name, this patch series still uses latency_tolerance as the task
attribute, but will change the name to the desired name on further
comments.


The patch series can be applied on tip/sched/core at the
commit de881a341c41 ("Merge branch 'sched/rt' into sched/core, to pick up commit")


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


Parth Shah (3):
  sched: Introduce latency-tolerance 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_tolerance of the
    task

 include/linux/sched.h            |  1 +
 include/uapi/linux/sched.h       |  4 +++-
 include/uapi/linux/sched/types.h | 19 +++++++++++++++++++
 kernel/sched/core.c              | 21 +++++++++++++++++++++
 kernel/sched/sched.h             | 18 ++++++++++++++++++
 tools/include/uapi/linux/sched.h |  4 +++-
 6 files changed, 65 insertions(+), 2 deletions(-)

-- 
2.17.2

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ