lkml.org 
[lkml]   [2017]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection
On Wed, May 24, 2017 at 10:50:53AM +0100, Juri Lelli wrote:

> Agreed. However, problem seems to be that
>
> - in my opinion (current implementation) this translated into scaling
> runtime considering current freq and cpu-max-capacity; and this is
> required when frequency scaling is enabled and we still want to meet
> a task's guaranteed bandwidth

Just so. The bandwidth they request is based on instructions/work. We
need to get a certain amount of instructions sorted. Nobody cares we get
an exact 10% at random frequency if they loose they finger because we
didn't get that final instruction out that stops the saw blade.

> - Luca seemed instead to be inclined to say that, if we scale runtime
> for !reclaim tasks, such tasks are basically allowed to run for more
> time (when frequency is lower than max) by using some of the
> bandwidth not allocated to themselves

Yes, that's a wrong view :-) We don't care about 'time', we care about
getting the instruction stream / work completed.

\
 
 \ /
  Last update: 2017-05-24 13:35    [W:0.071 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site