lkml.org 
[lkml]   [2007]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: sparc generic time / clockevents
    From
    Date
    On Fri, 2007-02-23 at 16:34 -0800, David Miller wrote:
    > From: john stultz <johnstul@us.ibm.com>
    > Date: Fri, 23 Feb 2007 11:51:18 -0800
    >
    > > Yea. I actually have some in-progress patches from Peter Keilty that
    > > convert ia64 and sparc64 time_interpolators to clocksources, then
    > > removes the time_interpolator code.
    > >
    > > The ia64 conversion is more complicated due to the fsyscall asm, but I
    > > think the sparc64 conversion (below) is pretty straight forward. I've
    > > only built tested this, so I have no clue if it actually works.
    > >
    > > Any thoughts?
    >
    > Hey John, I had to do this already in order to do the dynticks
    > port to sparc64, but nice to see another attempt :-)

    Oh! Well, sorry for not sending it out earlier, then!

    > Two things I did on my side:
    >
    > + .mask = 0xffffffffffffffffLL,
    >
    > I used CLOCKSOURCE_MASK(64) here.

    Yep. That's better.

    > +static cycle_t read_sparc64_cpuclock(void)
    > +{
    > + return (cycle_t)get_cycles();
    > +}
    > ...
    > + .read = read_sparc64_cpuclock,
    >
    > You can just directly assign tick_ops->get_tick to .read at run-time
    > to avoid a stack frame and function call/return.

    Cool.

    > + .shift = 16,
    >
    > These shift selections all seem rather arbitrary.
    >
    > If it's not an arbitrary selection, it would be nice to have some
    > comments about how to go about choosing an appropriate shift.
    > I imagine the selections has to do with the possible range of
    > the frequencies the clocksource supports, and how much
    > accuracy you get for certain shift selections given that range.

    Correct. The higher the shift value, the more precise NTP multiplier
    adjustment we can make. However, too large w/ a high frequency
    clocksource and you'll risk overflowing 64bits on the mult.

    Although that's not super critical anymore since Roman implemented the
    high-res error accounting, the net effect should be the same over the
    long term(we just have to work harder w/ courser adjustments - resulting
    in very small clock frequency oscillations).

    I do need to get some documentation going. I had some back when I first
    started pushing the changes, but so much was revised and rewritten it
    stopped being correct.

    -john

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-02-24 01:55    [W:4.163 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site