Messages in this thread | | | Subject | Re: [PATCH] sched: Support current clocksource handling in fallback sched_clock(). | From | john stultz <> | Date | Tue, 26 May 2009 13:40:39 -0700 |
| |
On Tue, 2009-05-26 at 22:30 +0200, Peter Zijlstra wrote: > On Tue, 2009-05-26 at 13:23 -0700, john stultz wrote: > > Overall, I'd probably suggest thinking this through a bit more. At some > > point doing this right will cause sched_clock() to be basically the same > > as ktime_get(). So why not just use that instead of remaking it? > > simply because we don't require the strict global monotonicy for > scheduling as we do from a regular time source (its nice to have > though). > > That means that on x86 we can always use TSC for sched_clock(), even > when its quite unsuitable for ktime.
Right, but I guess what I'm asking is can this be a bit better defined?
If we are going to use clocksources (or cyclecounters - an area I need to clean up soon), it would be good to get an idea of what is expected of the sched_clock() interface.
So TSC good, HPET bad. Why? Is latency all we care about? How bad would the TSC have to be before we wouldn't want to use it?
thanks -john
| |