Re: sched_clock() uses are broken

[Mike Galbraith <efault@gmx.de>]

On Wed, 2006-05-03 at 11:16 +0200, Andi Kleen wrote:
> On Wednesday 03 May 2006 11:11, Mike Galbraith wrote:
> > On Wed, 2006-05-03 at 09:40 +0200, Andi Kleen wrote:
> > > On Wednesday 03 May 2006 09:09, Mike Galbraith wrote:
> > > 
> > > > Given that most people are going to end up using the pm_timer anyway, I
> > > > don't see the point of even having a sched_clock().  If it's jiffy
> > > > resolution, it's useless.  If it's wildly inaccurate (as it is in the
> > > > SMP case, monotonicity issues aside) it's more than useless.
> > > 
> > > For sched_clock TSC is always used and it's fine - sched_clock
> > > doesn't require the guarantees that make TSC often useless otherwise
> > 
> > Regrettable, that's not true.
> 
> Hmm, maybe I'm thinking too much x86-64. At least on x86-64 it's true.
> 
> I don't see a big reason to not do this on i386 either, except
> on systems that truly don't have a TSC (386/486)

It should be this way on any system that has a half way functional high
resolution source.  Without it, the starvation scenario which
sched_clock() was invented to solve returns.  Making that the default
wasn't (um um um) the most brilliant selection among available options.

> Ok i suppose if you don't want cruft you can always go to 64bit @)

Unemployed guys can't buy new toys without wives getting all grumpy ;-)

	-Mike