lkml.org 
[lkml]   [2013]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [PATCH v3 09/22] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task
    On 01/07/2013 02:31 AM, Linus Torvalds wrote:
    > On Sat, Jan 5, 2013 at 11:54 PM, Alex Shi <alex.shi@intel.com> wrote:
    >>
    >> I just looked into the aim9 benchmark, in this case it forks 2000 tasks,
    >> after all tasks ready, aim9 give a signal than all tasks burst waking up
    >> and run until all finished.
    >> Since each of tasks are finished very quickly, a imbalanced empty cpu
    >> may goes to sleep till a regular balancing give it some new tasks. That
    >> causes the performance dropping. cause more idle entering.
    >
    > Sounds like for AIM (and possibly for other really bursty loads), we
    > might want to do some load-balancing at wakeup time by *just* looking
    > at the number of running tasks, rather than at the load average. Hmm?

    Millions thanks for your suggestions! :)

    It's worth to try use instant load -- nr_running in waking balancing, I
    will try this. but in this case, I tried to print sleeping tasks by
    print_task() in sched/debug.c. Find the 2000 tasks were forked on just 2
    LCPUs which in different cpu sockets whenever with/without this load avg
    patch.

    So, I am wondering if it's worth to consider the sleeping tasks' load in
    fork/wake balancing. Does anyone consider this in history?

    ===
    print_task(struct seq_file *m, struct rq *rq, struct task_struct *p)
    {
    if (rq->curr == p)
    SEQ_printf(m, "R");
    + else if (!p->on_rq)
    + SEQ_printf(m, "S");
    else
    SEQ_printf(m, " ");
    ...
    @@ -166,13 +170,14 @@ static void print_rq(struct seq_file *m, struct rq
    *rq, int rq_cpu)
    read_lock_irqsave(&tasklist_lock, flags);

    do_each_thread(g, p) {
    - if (!p->on_rq || task_cpu(p) != rq_cpu)
    + if (task_cpu(p) != rq_cpu)
    continue;
    ===

    >
    > The load average is fundamentally always going to run behind a bit,
    > and while you want to use it for long-term balancing, a short-term you
    > might want to do just a "if we have a huge amount of runnable
    > processes, do a load balancing *now*". Where "huge amount" should
    > probably be relative to the long-term load balancing (ie comparing the
    > number of runnable processes on this CPU right *now* with the load
    > average over the last second or so would show a clear spike, and a
    > reason for quick action).

    Many thanks for suggestion!
    Will try it. :)
    >
    > Linus
    >


    \
     
     \ /
      Last update: 2013-01-08 16:01    [W:6.153 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site