On 4 June 2018 at 12:12, Juri Lelli <juri.le...@redhat.com> wrote: > 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.
It's dl and cfs as the goal is to track cfs preempted by dl This means creating a new struct whereas some fields are unused in avg_dl struct And duplicate some call to ___update_load_sum as we track avg_dl for removing sched_rt_avg_update and update_dl/rt_rq_load_avg are already call in fair.c for updating blocked load > >> 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? we will not be able to make the difference between rt/dl/stop preemption by using only pick_next_task_fair Thanks > > Thanks, > > - Juri
