On Wed, Mar 06, 2013 at 05:10:53PM +0100, Thomas Gleixner wrote: > On Wed, 6 Mar 2013, Feng Tang wrote: > > Hi Thomas, > > > > Thanks for the reviews. > > > > On Wed, Mar 06, 2013 at 03:09:26PM +0100, Thomas Gleixner wrote: > > > On Wed, 6 Mar 2013, Feng Tang wrote: > > > > > > > Current clocksource_cyc2ns() has a implicit limit that the (cycles * > > > > mult) > > > > can not exceed 64 bits limit. Jason Gunthorpe proposed a way to > > > > handle this big cycles case, and this patch put the handling into > > > > clocksource_cyc2ns() so that it could be used unconditionally. > > > > > > Could be used if it wouldn't break the world and some more. > > > > Exactly. > > > > One excuse I can think of is usually the clocksource_cyc2ns() will be called > > for cycles less than 600 seconds, based on which the "mult" and "shift" are > > calculated for a clocksource. > > That's not an excuse for making even the build fail on ARM and other > 32bit archs.
That's a huge mistake I made in my patch, and I didn't meant to excuse for it :) > > > > trying to avoid expensieve maths. But as Jason pointed, there is some > > accuracy > > lost. > > Right, but if you precalculate the max_fast_cycles value you can avoid > at least the division in the fast path and then do > > if (cycles > max_fast_cycles) > return clocksource_cyc2ns_slow(); > return ((u64) cycles * mult) >> shift; > > clocksource_cyc2ns_slow() should be out of line and there you can do > all the slow 64 bit operations. That keeps the fast path sane and we > don't need extra magic for the large cycle values. Yeah! This should well cover all possilbe cycles and solve the fast/slow problem. Thanks. Will try to make a new patch. - Feng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
