Messages in this thread |  | | | From | "Chen, Kenneth W" <> | | Subject | RE: bug in sched.c:activate_task() | | Date | Tue, 5 Oct 2004 10:44:51 -0700 |
| |
* Chen, Kenneth W <kenneth.w.chen@intel.com> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |