Hi,
On Thu, 23 Jun 2005, john stultz wrote:
> > We basically have two timer architectures: timer tick and continuous
> > timer. The latter currently has to emulate the timer tick. Your patch
> > completely reverses the rolls and forces everybody to produce a continuous
> > timer, which I think is equally bad, as some simple computations become a
> > lot more complex. Why should it not be possible to support both equally?
>
> Yep, I think this is really the core contention.
>
> In my design I've reworked the time subsystem to assume time flows
> continuously as provided by the timesource. On systems that do not have
> a continuous counters like the PPC timebase, they can use a similar tick
> based interpolation method to provide continuous time. However this
> interpolation is done in the timesource driver instead of in the generic
> code.
By introducing extra overhead, which is difficult to get rid of again.
> > That might result in the worst of both worlds. If I look at the ppc64
> > implementation of gettimeofday, it's really nice and your (current) code
> > would make this worse again.
>
> Could you be more specific about how you feel the ppc64 is nice and how
> my code is worse? My code is actually quite influenced by the ppc64
> code, so specific details might help me respond.
The ppc64 converts the timebase directly to a timeval, your code puts the
nanosecond step inbetween.
> > So why not leave it to the timer source, if
> > it wants to manage a cycle counter or a xtime+offset? The common code can
> > provide some helper functions to manage either of this. Converting
> > everything to nanoseconds looks like a really bad compromise.
> >
> > In the ppc64 example the main problem is that the generic tries to adjust
> > for the wrong for the time source - the scheduler tick, which is derived
> > from the cycle counter, so it has to redo all the work. Your code now
> > introduces an abstract concept of nanosecond which adds extra overhead to
> > either timer concept. Why not integrating what ppc64 does into the current
> > timer code instead of replacing the current code with something else?
>
> I'm not sure I followed that paragraph. Would you clarify a bit?
What exactly?
> Computationally, there are two 64bit mult/shifts (in the interval
> calculations) and a 64 bit divide that occurs in my code. However this
> is only done every 50ms instead of every tick, so I don't believe there
> is much of a performance impact.
You forgot the cyc2ns conversions. Compare this now to some simple 32bit
math executed every 100ms. Just look at all 32bit archs which use the
generic do_div and you get an idea, who will not be happy with your new
code.
Why do you do the adjustment at _every_ call? Why don't you take advantage
of the fact, that you can be called regularly? In a tick based system you
can be called every n*tick_nsec ns (without even the need to read a
possibly expensive timer offset), in a cycle counter system you can
trigger a call when the counter is past a certain value. In either case
you know the callback function is called on average in a regular interval,
so you can precompute adjustments based on this. Ignoring this possibility
looks like a huge step back to me.
bye, Roman
-
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]
