Messages in this thread | | | Date | Wed, 27 May 2009 02:18:40 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH] sched: Support current clocksource handling in fallback sched_clock(). |
| |
On Wed, 27 May 2009, Paul Mundt wrote: > > Yea. So this is a little better. There's still a few other issues to > > consider: > > > > 1) What if a clocksource is registered that has the _SCHED_CLOCK bit > > set, but is not selected for timekeeping due it being unstable like the > > TSC? > > > See, this is what I thought the rating information was useful for, as the > rating is subsequently dropped if it is not usable. But perhaps it makes > more sense to just clear the bit at the same time that the rating is > lowered once it turns out to be unstable.
Stop worrying about TSC please. The x86 f*cked up timers need special handling which is definitely not required for most of arch/*. x86 overrides that anyway and handles the TSC f*ckup in the CONFIG_HAVE_UNSTABLE_SCHED_CLOCK section of sched_clock.c which is completely irrelevant to any architecture which has a sane set of timers.
The only extra magic which is required to avoid that (sub)arch maintainers need to specify a sched_clock() implementation to override the weak generic one is really the simple
if (clock && (clock->flags & CLOCKSOURCE_USE_FOR_SCHED_CLOCK)) return ....
We need no locking there at all.
We have a workaround in place, which overrides the weak sched_clock() implementation, to make x86 efficient, so why do we want to impose all that x86 crap on folks which deal with architectures which got the timers right ?
Thanks,
tglx
| |