lkml.org 
[lkml]   [2018]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v5 05/10] cpufreq/schedutil: get max utilization
On 4 June 2018 at 09:04, Juri Lelli <juri.lelli@redhat.com> wrote:
> Hi Vincent,
>
> On 04/06/18 08:41, Vincent Guittot wrote:
>> On 1 June 2018 at 19:45, Joel Fernandes <joelaf@google.com> wrote:
>> > On Fri, Jun 01, 2018 at 03:53:07PM +0200, Vincent Guittot wrote:
>
> [...]
>
>> > IMO I feel its overkill to account dl_avg when we already have DL's running
>> > bandwidth we can use. I understand it may be too instanenous, but perhaps we
>>
>> We keep using dl bandwidth which is quite correct for dl needs but
>> doesn't reflect how it has disturbed other classes
>>
>> > can fix CFS's problems within CFS itself and not have to do this kind of
>> > extra external accounting ?
>
> I would also keep accounting for waiting time due to higher prio classes
> all inside CFS. My impression, when discussing it with you on IRC, was
> that we should be able to do that by not decaying cfs.util_avg when CFS
> is preempted (creating a new signal for it). Is not this enough?

We don't just want to not decay a signal but increase the signal to
reflect the amount of preemption
Then, we can't do that in a current signal. So you would like to add
another metrics in cfs_rq ?
The place doesn't really matter to be honest in cfs_rq or in dl_rq but
you will not prevent to add call in dl class to start/stop the
accounting of the preemption

>
> I feel we should try to keep cross-class accounting/interaction at a
> minimum.

accounting for cross class preemption can't be done without
cross-class accounting

Regards,
Vincent

>
> Thanks,
>
> - Juri

\
 
 \ /
  Last update: 2018-06-04 09:15    [W:0.131 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site