Messages in this thread | | | Date | Tue, 07 May 2013 08:24:43 +0800 | From | Alex Shi <> | Subject | Re: [PATCH v5 5/7] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task |
| |
> 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
| |