lkml.org 
[lkml]   [2023]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Re: [PATCH 03/15] sched/fair: Add lag based placement
From
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..

\
 
 \ /
  Last update: 2023-10-13 10:16    [W:0.198 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site