On 10/2/19 9:11 AM, David Laight wrote:
> From: Parth Shah
>> Sent: 30 September 2019 11:44
> ...
>> 5> Separating AVX512 tasks and latency sensitive tasks on separate cores
>> ( -Tim Chen )
>> ===
>> Another usecase we are
On 10/2/19 9:41 PM, David Laight wrote:
> From: Parth Shah
>> Sent: 30 September 2019 11:44
> ...
>> 5> Separating AVX512 tasks and latency sensitive tasks on separate cores
>> ( -Tim Chen )
>> ===
>> Another usecase we are
From: Parth Shah
> Sent: 30 September 2019 11:44
...
> 5> Separating AVX512 tasks and latency sensitive tasks on separate cores
> ( -Tim Chen )
> ===
> Another usecase we are considering is to segregate those workload that
Hello everyone,
This is the v2 of the discussion started for introducing per-task
latency-nice attribute for providing scheduler hints.
v1: https://lkml.org/lkml/2019/9/18/555
In brief, we face two challenges with the introduction of such attr.
1. Name:
==
( Should be relevant to
Hi!
> > I don't want to start a bikeshedding session here, but I agree with Parth
> > on the interpretation of the values.
> >
> > I've always read niceness values as
> > -20 (least nice to the system / other processes)
> > +19 (most nice to the system / other processes)
> >
> > So following
On 9/19/19 8:13 PM, Qais Yousef wrote:
> On 09/18/19 18:11, Parth Shah wrote:
>> 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
On 19/09/2019 17:41, Parth Shah wrote:
> So jotting down separately, in case if we think to have "latency-nice"
> terminology, then we might need to select one of the 2 interpretation:
>
> 1).
>> -20 (least nice to latency, i.e. sacrifice latency for throughput)
>> +19 (most nice to latency, i.e.
On 9/18/19 9:12 PM, Valentin Schneider wrote:
> On 18/09/2019 15:18, Patrick Bellasi wrote:
>>> 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
On 9/19/19 2:06 AM, David Laight wrote:
> From: Tim Chen
>> Sent: 18 September 2019 18:16
> ...
>> Some users are running machine learning batch tasks with AVX512, and have
>> observed
>> that these tasks affect the tasks needing a fast response. They have to
>> rely on manual CPU affinity to
On 9/19/19 1:37 AM, Parth Shah wrote:
>
>>
>> $> Separating AVX512 tasks and latency sensitive tasks on separate cores
>> -
>> Another usecase we are considering is to segregate those workload that will
>> pull down
>> core
On 09/18/19 18:11, Parth Shah wrote:
> 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
From: Tim Chen
> Sent: 18 September 2019 18:16
...
> Some users are running machine learning batch tasks with AVX512, and have
> observed
> that these tasks affect the tasks needing a fast response. They have to
> rely on manual CPU affinity to separate these tasks. With appropriate
> latency
On 9/18/19 10:46 PM, Tim Chen wrote:
> On 9/18/19 5:41 AM, Parth Shah wrote:
>> 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
On 9/18/19 7:48 PM, Patrick Bellasi wrote:
>
> On Wed, Sep 18, 2019 at 13:41:04 +0100, Parth Shah wrote...
>
>> Hello everyone,
>
> Hi Parth,
> thanks for staring this discussion.
>
> [ + patrick.bell...@matbug.net ] my new email address, since with
> @arm.com I will not be reachable
On 9/18/19 5:41 AM, Parth Shah wrote:
> 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
On Wed, 18 Sep 2019 at 17:46, Patrick Bellasi wrote:
>
>
> On Wed, Sep 18, 2019 at 16:22:32 +0100, Vincent Guittot wrote...
>
> > On Wed, 18 Sep 2019 at 16:19, Patrick Bellasi
> > wrote:
>
> [...]
>
> >> $> Wakeup path tunings
> >> ==
> >>
> >> Some additional possible
On Wed, Sep 18, 2019 at 16:22:32 +0100, Vincent Guittot wrote...
> On Wed, 18 Sep 2019 at 16:19, Patrick Bellasi wrote:
[...]
>> $> Wakeup path tunings
>> ==
>>
>> Some additional possible use-cases was already discussed in [3]:
>>
>> - dynamically tune the policy of
On 18/09/2019 15:18, Patrick Bellasi wrote:
>> 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
>
> If by "lower value"
On Wed, 18 Sep 2019 at 16:19, Patrick Bellasi wrote:
>
>
> On Wed, Sep 18, 2019 at 13:41:04 +0100, Parth Shah wrote...
>
> > Hello everyone,
>
> Hi Parth,
> thanks for staring this discussion.
>
> [ + patrick.bell...@matbug.net ] my new email address, since with
> @arm.com I will not be reachable
On Wed, Sep 18, 2019 at 13:41:04 +0100, Parth Shah wrote...
> Hello everyone,
Hi Parth,
thanks for staring this discussion.
[ + patrick.bell...@matbug.net ] my new email address, since with
@arm.com I will not be reachable anymore starting next week.
> As per the discussion in LPC2019, new
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
21 matches
Mail list logo
