Messages in this thread | | | Date | Tue, 21 Mar 2023 21:58:13 +0800 | From | Chen Yu <> | Subject | Re: [PATCH 06/10] sched/fair: Add avg_vruntime |
| |
On 2023-03-06 at 14:25:27 +0100, Peter Zijlstra wrote: [...] > > +/* > + * Compute virtual time from the per-task service numbers: > + * > + * Fair schedulers conserve lag: \Sum lag_i = 0 > + * > + * lag_i = S - s_i = w_i * (V - v_i) > + * The definination of above lag_i seems to be inconsistent with the defininatin of se->lag in PATCH 8. Maybe rename lag_i to something other to avoid confusion? > + * \Sum lag_i = 0 -> \Sum w_i * (V - v_i) = V * \Sum w_i - \Sum w_i * v_i = 0 > + * > + * From which we solve V: > + * > + * \Sum v_i * w_i > + * V = -------------- > + * \Sum w_i > + * > + * However, since v_i is u64, and the multiplcation could easily overflow > + * transform it into a relative form that uses smaller quantities: > + * > + * Substitute: v_i == (v_i - v) + v > + * > + * \Sum ((v_i - v) + v) * w_i \Sum (v_i - v) * w_i > + * V = -------------------------- = -------------------- + v > + * \Sum w_i \Sum w_i > + * > + * Not sure if I understand it correctly, does it mean (v_i - v) * w_i will not overflow? If the weight of task is 15 (nice 19), then if v_i - v > (S64_MAX / 15) it gets overflow. Is it possible that v_i is much larger than cfs_rq->min_vruntime in this case?
thanks, Chenyu
| |