[lkml]   [2004]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: bug in sched.c:activate_task()
    * Chen, Kenneth W <> wrote:
    > Update p->timestamp to "now" in activate_task() doesn't look right to
    > me at all. p->timestamp records last time it was running on a cpu.
    > activate_task shouldn't update that variable when it queues a task on
    > the runqueue.

    Ingo Molnar wrote on Tuesday, October 05, 2004 1:19 AM
    > it is being used for multiple purposes: measuring on-CPU time, measuring
    > on-runqueue time (for interactivity) and measuring off-runqueue time
    > (for interactivity). It is also used to measure cache-hotness, by the
    > balancing code.
    > now, this particular update of p->timestamp:
    > > @@ -888,7 +888,6 @@ static void activate_task(task_t *p, run
    > > - p->timestamp = now;
    > is important for the interactivity code that runs in schedule() - it
    > wants to know how much time we spent on the runqueue without having run.
    > but you are right that the task_hot() use of p->timestamp is incorrect
    > for freshly woken up tasks - we want the balancer to be able to re-route
    > tasks to another CPU, as long as the task has not hit the runqueue yet
    > (which it hasnt where we consider it in the balancer).
    > the clean solution is to separate the multiple uses of p->timestamp:
    > with the patch below p->timestamp is purely used for the interactivity
    > code, and p->last_ran is for the rebalancer. The patch is ontop of your
    > task_hot() fix-patch. Does this work for your workload?

    I will take this for a spin and report back the result.

    - Ken

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:06    [W:0.020 / U:9.972 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site