Re: Voyager subarchitecture for 2.5.46

[john stultz <johnstul@us.ibm.com>]

On Mon, 2002-11-11 at 14:49, J.E.J. Bottomley wrote:
> johnstul@us.ibm.com said:
> > We'd still need to go back and yank out the #ifdef CONFIG_X86_TSC'ed
> > macros in profile.h and pksched.h or replace them w/ inlines that wrap
> > the rdtsc calls w/ if(cpu_has_tsc && !tsc_disable) or some such line.
> 
> Actually, the best way to do this might be to vector the rdtsc calls through a 
> function pointer (i.e. they return zero always if the TSC is disabled, or the 
> TSC value if it's OK).  I think this might be better than checking the 
> cpu_has_tsc flag in the code (well it's more expandable anyway, it won't be 
> faster...)

Sounds good, I'm planning on moving get_cycles to timer_opts, so how
about using that?

> When the TSC code is sorted out on a per cpu basis, consumers are probably 
> going to expect rdtsc to return usable values whatever CPU it is called on, so 
> vectoring the calls now may help this.

Yea, this is an ugly topic. I'm really not very enthusiastic about
per-cpu tsc, because it doesn't necessarilly solve the problem on the
few machines that can't use the global tsc implementation (such as the
x440). True, many of the points Linus made about the current timer_tsc
implementation are valid. It does need to be cleaned up further, and I
have some patches to do so (I'll resend tomorrow, as I'm out sick
today). We should be looking towards multi-frequency systems, and seeing
what we can do to clean things up (ie: cpu_khz is global, etc). 

If you are deadset on doing the percpu method, I'd strongly suggest
creating a new timer_per_cpu_tsc timer_opt struct and implementing it
there, rather then munging the existing code, which works well for most
systems. 

thanks
-john