Re: [PATCH v5 5/7] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task

[Alex Shi <alex.shi@intel.com>]

> The load-balancer has a longer time horizon; think of blocked_loag_avg
> to be a signal for the load, already assigned to this cpu, which is
> expected to appear (within roughly the next quantum).
> 
> Consider the following scenario:
> 
> tasks: A,B (40% busy), C (90% busy)
> 
> Suppose we have:
> CPU 0:  CPU 1:
>  A            C
>  B
> 
> Then, when C blocks the load balancer ticks.
> 
> If we considered only runnable_load then A or B would be eligible for
> migration to CPU 1, which is essentially where we are today.

Thanks for re-clarify. Yes, that's the value of blocked_load_avg here. :)
Anyway, will try to measure them by some benchmarks.
> 
>>
>> But your concern is worth to try. I will change the patchset and give
>> the testing results.
>> I guess not, the old load.weight is unsigned long, and runnable_load_avg
>> is smaller than the load.weight. so it should be fine.
>>
>> btw, according to above reason, guess move runnable_load_avg to
>> 'unsigned long' type is ok, do you think so?
>>
> 
> Hmm, so long as it's unsigned long and not u32 that should be OK.
> 
> From a technical standpoint:
> We make the argument that we run out of address space before we can
> overflow load.weight in the 32-bit case, we can make the same argument
> here.

thanks for the comments and input! :)
> 
>>
>> --
>> Thanks
>>     Alex


-- 
Thanks
    Alex