Re: [RFC][PATCH] sched_clock_cpu()

[Ingo Molnar]

* Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:

> Hi,
> 
> This is my current proposal to replace the rq->clock stuff (and 
> possibly cpu_clock()).
> 
> it _DOESN'T_ boot ;-/ and I seem to have caught a flu that makes my 
> whole body hurt like hell, so I'm not getting anything done.

ouch - getter better soon!

> Brain dump before I crash:
> 
>  - architectures that have a 'perfect' hardware clock can set
>      CONFIG_HAVE_STABLE_CLOCK

ok.

>  - the 'jiffie' window might be superfulous when we update tick_gtod
>    before the __update_sched_clock() call in sched_clock_tick()
> 
>  - cpu_clock() might be implemented as:
> 
>      sched_clock_cpu(smp_processor_id())
> 
>    if the accuracy proves good enough - how far can TSC drift in a
>    single jiffie when considering the filtering and idle hooks?

it 'can' be very bad - so we have to assume it's random and fall back to 
jiffies quality in that case. In practice on most x86 CPUs it wont drift 
that far - even drifting TSCs drift minimally (there are AMD 
Athlon64/Opteron CPUs where a CPU in HLT will cause the clock and the 
TSC to drift a bit) - and stopping TSCs will just stop.

But in terms of BIOSes trying to fix things up and in terms of cpufreq 
artifacts (the CPU's clock itself going through transients) anything can 
happen and the code must be robust.
 
>  - what other architectures besides x86 would need this?

we rarely get any interactivity reports from anything non-x86 so i doubt 
it truly matters on anything but x86. If it _breaks_ in terms of 
crashing or locking we do hear from other architectures ;-)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/