On 04/06/18 09:14, Vincent Guittot wrote: > On 4 June 2018 at 09:04, Juri Lelli <juri.le...@redhat.com> wrote: > > Hi Vincent, > > > > On 04/06/18 08:41, Vincent Guittot wrote: > >> On 1 June 2018 at 19:45, Joel Fernandes <joe...@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
OK. > Then, we can't do that in a current signal. So you would like to add > another metrics in cfs_rq ? Since it's CFS related, I'd say it should fit in CFS. > 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 Mmm, can't we distinguish in, say, pick_next_task_fair() if prev was of higher prio class and act accordingly? Thanks, - Juri
