Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Parth Shah <parth@linux.ibm.com>
Subject: Usecases for the per-task latency-nice attribute
To:     linux-kernel@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Patrick Bellasi <patrick.bellasi@arm.com>,
        subhra mazumdar <subhra.mazumdar@oracle.com>,
        tim.c.chen@linux.intel.com,
        Valentin Schneider <valentin.schneider@arm.com>
Cc:     mingo@redhat.com, morten.rasmussen@arm.com,
        dietmar.eggemann@arm.com, pjt@google.com,
        vincent.guittot@linaro.org, quentin.perret@arm.com,
        dhaval.giani@oracle.com, daniel.lezcano@linaro.org, tj@kernel.org,
        rafael.j.wysocki@intel.com, qais.yousef@arm.com
Date:   Wed, 18 Sep 2019 18:11:04 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-Id: <3e5c3f36-b806-5bcc-e666-14dc759a2d7b@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hello everyone,

As per the discussion in LPC2019, new per-task property like latency-nice
can be useful in certain scenarios. The scheduler can take proper decision
by knowing latency requirement of a task from the end-user itself.

There has already been an effort from Subhra for introducing Task
latency-nice [1] values and have seen several possibilities where this type of
interface can be used.

From the best of my understanding of the discussion on the mail thread and
in the LPC2019, it seems that there are two dilemmas;

1. Name: What should be the name for such attr for all the possible usecases?
=============
Latency nice is the proposed name as of now where the lower value indicates
that the task doesn't care much for the latency and we can spend some more
time in the kernel to decide a better placement of a task (to save time,
energy, etc.)
But there seems to be a bit of confusion on whether we want biasing as well
(latency-biased) or something similar, in which case "latency-nice" may
confuse the end-user.

2. Value: What should be the range of possible values supported by this new
attr?
==============
The possible values of such task attribute still need community attention.
Do we need a range of values or just binary/ternary values are sufficient?
Also signed or unsigned and so the length of the variable (u64, s32, etc)?


This mail is to initiate the discussion regarding the possible usecases of
such per task attribute and to come up with a specific name and value for
the same.

Hopefully, interested one should plot out their usecase for which this new
attr can potentially help in solving or optimizing it.


Well, to start with, here is my usecase.

-------------------
**Usecases**
-------------------

$> TurboSched
====================
TurboSched [2] tries to minimize the number of active cores in a socket by
packing an un-important and low-utilization (named jitter) task on an
already active core and thus refrains from waking up of a new core if
possible. This requires tagging of tasks from the userspace hinting which
tasks are un-important and thus waking-up a new core to minimize the
latency is un-necessary for such tasks.
As per the discussion on the posted RFC, it will be appropriate to use the
task latency property where a task with the highest latency-nice value can
be packed.
But for this specific use-cases, having just a binary value to know which
task is latency-sensitive and which not is sufficient enough, but having a
range is also a good way to go where above some threshold the task can be
packed.


References:
===========
[1]. https://lkml.org/lkml/2019/8/30/829
[2]. https://lkml.org/lkml/2019/7/25/296