lkml.org 
[lkml]   [2003]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] 2.6.0-test11 sched_clock() broken for "drifty ITC"
* John Hawkes <hawkes@babylon.engr.sgi.com> wrote:

> Some amount of code would need to be added to sched.c to deal with
> unsynchronized values: scheduler_tick() remembers a local jiffies-
> granularity sched_clock() in the runqueue struct, and load_balance's
> can_migrate_task() uses that saved timestamp to compare against the
> tested task->timestamp to determine cache-hot-or-not, rather than
> using the local CPU's sched_clock() value. Also, task->timestamp
> needs to be readjusted when the task migrates:

this is a tough problem that wont go away.

Even platforms where the per-CPU clock is supposed to be synchronized,
sometimes it isnt. (this is a recurring problem on x86 SMP - so x86 will
benefit from it too.)

the relaxation means the effective granularity reduction of the
migration decisions - but this is not a problem, migration latencies are
always a high multiple of the timer irq frequency. The cycle accuracy of
sched_clock() is otherwise very important for correct interactivity
decisions - but this is only used locally and is thus preserved by the
patch. The only area where this change can reduce the quality of
interactivity estimatio is when a task oscillates very quickly between
multiple CPUs and is also somehow relevant to interactivity.

So i believe the generic relaxing of sched_clock() synchronization is
the right thing to do. I like your patch. It adds minimal overhead and
solves a hard problem - nice work! Andrew, please apply it.

Ingo
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.104 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site