Messages in this thread | | | Date | Fri, 13 Oct 2023 16:14:55 +0800 | Subject | Re: Re: [PATCH 03/15] sched/fair: Add lag based placement | From | Abel Wu <> |
| |
On 10/13/23 3:37 PM, Peter Zijlstra Wrote: > On Thu, Oct 12, 2023 at 03:04:47PM +0800, Abel Wu wrote: >> On 10/11/23 9:24 PM, Peter Zijlstra Wrote: > >>>>> + * we should inflate the lag before placement such that the >>>>> + * effective lag after placement comes out right. >>>>> + * >>>>> + * As such, invert the above relation for vl'_i to get the vl_i >>>>> + * we need to use such that the lag after placement is the lag >>>>> + * we computed before dequeue. >>>>> + * >>>>> + * vl'_i = vl_i - w_i*vl_i / (W + w_i) >>>>> + * = ((W + w_i)*vl_i - w_i*vl_i) / (W + w_i) >>>>> + * >>>>> + * (W + w_i)*vl'_i = (W + w_i)*vl_i - w_i*vl_i >>>>> + * = W*vl_i >>>>> + * >>>>> + * vl_i = (W + w_i)*vl'_i / W >>> >>> And then we obtain the scale factor: (W + w_i)/W, which is >1, right? >> >> Yeah, I see. But the scale factor is only for the to-be-placed entity. >> Say there is an entity k on the tree: >> >> vl_k = V - v_k >> >> adding the to-be-placed entity i affects this by: >> >> define delta := w_i*vl_i / (W + w_i) >> >> vl'_k = V' - v_k >> = V - delta - (V - vl_k) >> = vl_k - delta >> >> hence for any entity on the tree, its lag is offsetted by @delta. So >> I wonder if we should simply do offsetting rather than scaling. > > I don't see the point, the result is the same and computing delta seems > numerically less stable.
Right. I was not myself then, please forget what I said..
| |