Re: [PATCH] - sched_clock() broken for ia64 SN platform

From: John Hawkes <hawkes_at_sgi.com>
Date: 2003-11-21 07:58:20
From: "David Mosberger" <davidm@napali.hpl.hp.com>
>   Jack Steiner> However, reading the ITC is faster & preferred if intercpu
>   Jack Steiner> drift is not an issue.
>
> Yes.  Plus we could solve the problem once and for all, not once for
> each drifty platform.
>
> As I remember it, sched_clock() was originally invented to measure
> fine-grained "how long have I run" times.  This can be done with ITC
> without synchronization, since the start and stop "times" will be
> measured on the same CPU.  Howver, as John points out, at the moment
> sched_clock() is also used for migration-decisions.  My guess is that
> this part is just due to someone trying to be overly clever.  At least
> on drifty platforms, you can just as easily make this decision based
> on jiffies.  All it would do is add one word to the task_struct and
> reading both sched_clock() and jiffies when updating the timestamp(s).

I doubt this double-count would ever be accepted by the wider Linux Community,
as it bloats mainline arch-independent code, just to fix a problem with a
handful of drifty platforms.

The i386 code is uglier than my patch, as it makes NUMA platforms use the
gross-granularity "jiffies" as the time base.  So much for any of the benefits
in the scheduler to a high-precision task->timestamp.  At least with my ia64
patch, it allows for a platform-specific sched_clock() that returns a
high-precision value and doesn't appreciably add bloat.

John Hawkes


-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Thu Nov 20 16:01:34 2003

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:20 EST