Messages in this thread | | | Date | Tue, 5 Jun 2018 12:43:44 -0700 | From | Joel Fernandes <> | Subject | Re: [PATCH 2/2] sched/fair: util_est: add running_sum tracking |
| |
On Tue, Jun 05, 2018 at 12:33:17PM -0700, Joel Fernandes wrote: > On Tue, Jun 05, 2018 at 04:21:56PM +0100, Patrick Bellasi wrote: [..] > > To be more precise, at each ___update_load_avg we should really update > > running_avg by: > > > > u32 divider = LOAD_AVG_MAX - 1024 + sa->period_contrib; > > sa->running_avg = sa->running_sum / divider; > > > > but, this would imply tracking an additional signal in sched_avg and > > doing an additional division at ___update_load_avg() time. > > > > Morten suggested that, if we accept the rounding errors due to > > considering > > > > divider ~= LOAD_AVG_MAX > > > > thus discarding the (sa->period_contrib - 1024) correction, then we > > can completely skip the tracking of running_avg (thus saving space in > > sched_avg) and approximate it at dequeue time as per the code line, > > just to compute the new util_est sample to accumulate. > > > > Does that make sense now? > > The patch always made sense to me.. I was just pointing out the extra > division this patch adds. I agree since its done on dequeue-only, then its > probably Ok to do.. >
One thing to note about this error is I remember not compensating for it would make the utilization reduce... which is kind of weird. But yeah if we can find a way compensate for the error and also keep the overhead low, that's super.. I know this is probably low in priority considering the other concerns Vincent brought up which are being discussed in the other thread,.. but just saying. :)
- Joel
| |