On 08.09.2005 [13:00:36 +0300], Tony Lindgren wrote:
> * Nishanth Aravamudan <[EMAIL PROTECTED]> [050907 18:07]:
> > On 07.09.2005 [10:37:43 +0300], Tony Lindgren wrote:
> > > * Nishanth Aravamudan <[EMAIL PROTECTED]> [050905 20:02]:
> > > > On 05.09.2005 [10:27:05 +0300], Tony Lindgren wrote:
> > > > > * Srivatsa Vaddagiri <[EMAIL PROTECTED]> [050905 10:03]:
> > > > > > On Sun, Sep 04, 2005 at 01:10:54PM -0700, Nishanth Aravamudan wrote:
> > > > > > >
> > > > > > > Also, I am a bit confused by the use of "dynamic-tick" to
> > > > > > > describe these
> > > > > > > changes. To me, these are all NO_IDLE_HZ implementations, as they
> > > > > > > are
> > > > > > > only invoked from cpu_idle() (or their equivalent) routines. I
> > > > > > > know this
> > > > > > > is true of s390 and the x86 code, and I believe it is true of the
> > > > > > > ARM
> > > > > > > code? If it were dynamic-tick, I would think we would be
> > > > > > > adjusting the
> > > > > > > timer interrupt frequency continuously (e.g., at the end of
> > > > > > > __run_timers() and at every call to {add,mod,del}_timer()). I was
> > > > > > > working on a patch which did some renaming to no_idle_hz_timer,
> > > > > > > etc.,
> > > > > > > but it's mostly code churn :)
> > > > > >
> > > > > > Yes, the name 'dynamic-tick' is misleading!
> > > > >
> > > > > Huh? For most people dynamic-tick is much more descriptive name than
> > > > > NO_IDLE_HZ or VST!
> > > >
> > > > I understand this. My point is that the structures are *not*
> > > > dynamic-tick specific. They are interrupt source specific, generally
> > > > (also known as hardware timers) -- dynamic tick or NO_IDLE_HZ are the
> > > > users of the interrupt source reprogramming functions, but not the
> > > > reprogrammers themselves, in my mind. Also, it still would be confusing
> > > > to use dynamic-tick, when the .config option is NO_IDLE_HZ! :)
> > >
> > > I see what you mean, it's a confusing naming issue currently :) Would
> > > the following solution work for you:
> > >
> > > - Dynamic tick is the structure you register with, and then you use it
> > > for any kind of non-continuous timer tinkering
> > >
> > > - This structure has at least two possible users, NO_IDLE_HZ and
> > > sub-jiffie timers
> > >
> > > So we could have following config options:
> > >
> > > CONFIG_DYNTICK
> > > CONFIG_NO_IDLE_HZ depends on dyntick
> > > CONFIG_SUBJIFFIE_TIMER depends on dyntick
> >
> > Hrm, yes, first you are right with the dependency ordering. I take it
> > CONFIG_DYNTICK is simply there as NO_IDLE_HZ and SUBJIFFIE_TIMER are
> > independent users of the same underlying infrastructure.
>
> Cool, I'm glad we got the dependencies figured out now rather than later :)
Yup, I think that makes the most sense. I appreciate your help with it!
> > > > > If you wanted, you could reprogram the next timer to happen from
> > > > > {add,mod,del}_timer() just by calling the timer_dyn_reprogram() there.
> > > >
> > > > I messed with this with my soft-timer rework (which has since has fallen
> > > > by the wayside). It is a bit of overhead, especially del_timer(), but
> > > > it's possible. This is what I would consider "dynamic-tick." And I would
> > > > setup a *different* .config option to enable it. Perhaps depending on
> > > > CONFIG_NO_IDLE_HZ.
> > >
> > > Yes, I agree it should be a different .config option. Maybe the example
> > > above would work for that?
> >
> > Yes, I'm thinking it might.
> >
> > > > > And you would want to do that if you wanted sub-jiffie timer
> > > > > interrupts.
> > > >
> > > > Yes, true, it does enable that. Well, to be honest, it completely
> > > > redefines (in some sense) the jiffy, as it is potentially continuously
> > > > changing, not just at idle times.
> > >
> > > Yeah. But should still work as we already accept interrupts at any point
> > > inbetween jiffies to update time, and update the system time from a
> > > second continuously running timer :)
> >
> > The problem with subjiffie timers is that the precision of soft-timers
> > is jiffies currently. It requires some serious effort to modify the
> > soft-timer subsystem to be aware of the extra bits it needs,
> > efficiently -- take a look at what HRT has had to do.
>
> Yes, we should coordinate that with HRT. BTW, we can reduce the overhead
> of del_timer() by _not_ calling next_timer_interrupt(), and programming
> the next timer interrupt to happen where next jiffie would be. Then once
> we get to the idle, we call next_timer_interrupt()...
Yes, I agree with the del_timer() changes.
> > > > > So I'd rather not limit the name to the currently implemented
> > > > > functionality only :)
> > > >
> > > > I'm not trying to limit the name, but make sure we are tying the
> > > > strcutures and functions to the right abstraction (interrupt source, in
> > > > my opinion).
> > >
> > > But other devices are interrupt sources too... And really the only use
> > > for this stuct is non-continuous timer stuff, right?
> >
> > Would "tick_source" be better? I guess you are right, that there is only
> > this one consumer... Although if that is the case, then maybe a separate
> > .h/.c file is the right way to go, to isolate the code, reduce
> > #ifdeffery in timer.h/.c.
>
> Hmmm, seems like dyntick.[ch] is still the best name for it...
I guess you are right, I'll change my little summary and send it out so
it's archived.
Thanks,
Nish
-
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/
