Messages in this thread |  | | | Date | Wed, 27 May 2009 02:27:21 +0200 (CEST) | | From | Thomas Gleixner <> | | Subject | Re: [PATCH] sched: Support current clocksource handling in fallback sched_clock(). |
| |
John,
On Tue, 26 May 2009, john stultz wrote: > > 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. > > Yes, if we're dropping a clocksource we should also drop the bit. That > shouldn't be a problem. > > The point I was making, is that multiple clocksources may be registered > at one time (TSC, ACPI_PM, etc). But only one is being managed by the > timekeeping code (clock). So there may be the case where the > sched_clock() is different then the timekeeping clock (which is common > on x86). > > So I suspect we need a special hook that grabs the best _SCHED_CLOCK > clocksource (as computed at clocksource registration time) and provides > it to the generic sched_clock() interface.
this is not about x86 and its inferiour timer hardware implementation. We talk about sane architectures which do not have that problems at all. x86 takes a different code path and overrides the generic weak sched_clock implememtation anyway. So what ?
Thanks,
tglx
|  |