On Thu, 2007-07-19 at 19:38 +0200, Andi Kleen wrote:
> On Thursday 19 July 2007 19:31:56 Daniel Walker wrote:
>
> > >From my perspective a downside to sched_clock is that the math is
> > duplicated per architecture .. I think it would be a win to use the
> > generic functions if it's possible..
>
> They can't be used because they're not cpu local. The whole basic
> concept behind the new sched_clock is to be cpu local.
Your not following me .. The cpu localness is retained in the multiply
value, which is component of the math .. It's got nothing to do with the
conversion code itself.
You do the same operation to convert from cycles to nanosecond
regardless of the values you use. Example,
+static inline u64 __cycles_2_ns(struct sc_data *sc, u64 cyc)
+{
+ u64 ns;
+
+ cyc -= sc->sync_base;
+ ns = (cyc * sc->cyc2ns_scale) >> CYC2NS_SCALE_FACTOR;
+ ns += sc->ns_base;
+
+ return ns;
+}
Above the line "(cyc * sc->cyc2ns_scale) >> CYC2NS_SCALE_FACTOR;" is
part of the duplication that I'm referring to, not the surrounding code.
Which looks very much like this,
static inline s64 cyc2ns(struct clocksource *cs, cycle_t cycles)
{
u64 ret = (u64)cycles;
ret = (ret * cs->mult) >> cs->shift;
return ret;
}
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
