Messages in this thread | | | Date | Mon, 5 Sep 2005 10:02:02 -0700 | From | Nishanth Aravamudan <> | Subject | Re: [PATCH 1/3] dynticks - implement no idle hz for x86 |
| |
On 05.09.2005 [10:27:05 +0300], Tony Lindgren wrote: > * Srivatsa Vaddagiri <vatsa@in.ibm.com> [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! :)
> 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.
> 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.
> 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).
Thanks, Nish - 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/
| |