lkml.org 
[lkml]   [2013]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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


    \
     
     \ /
      Last update: 2013-05-07 03:21    [W:2.487 / U:0.500 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site