Re: [PATCH 1/3] dynticks - implement no idle hz for x86

From: Tony Lindgren
Date: Mon Sep 05 2005 - 02:00:46 EST


* Nishanth Aravamudan <nacc@xxxxxxxxxx> [050904 23:38]:
> On 04.09.2005 [21:26:16 +0100], Russell King wrote:
> > On Sun, Sep 04, 2005 at 01:10:54PM -0700, Nishanth Aravamudan wrote:
> > > I've got a few ideas that I think might help push Con's patch coalescing
> > > efforts in an arch-independent fashion.
> >
> > Note that ARM contains cleanups on top of Tony's original work, on
> > which the x86 version is based.
> >
> > Basically, Tony submitted his ARM version, we discussed it, fixed up
> > some locking problems and simplified it (it contained multiple
> > structures which weren't necessary, even in multiple timer-based systems).
>
> Make sense. Thanks for the quick feedback!
>
> > I'd be really surprised if any architecture couldn't use what ARM has
> > today - in other words, this is the only kernel-side interface:
> >
> > #ifdef CONFIG_NO_IDLE_HZ
> >
> > #define DYN_TICK_SKIPPING (1 << 2)
> > #define DYN_TICK_ENABLED (1 << 1)
> > #define DYN_TICK_SUITABLE (1 << 0)
> >
> > struct dyn_tick_timer {
> > unsigned int state; /* Current state */
> > int (*enable)(void); /* Enables dynamic tick */
> > int (*disable)(void); /* Disables dynamic tick */
> > void (*reprogram)(unsigned long); /* Reprograms the timer */
> > int (*handler)(int, void *, struct pt_regs *);
> > };
> >
> > void timer_dyn_reprogram(void);
> > #else
> > #define timer_dyn_reprogram() do { } while (0)
> > #endif
>
> That looks great! So I guess I'm just suggesting moving this from
> include/asm-arch/mach/time.h to arch-independent headers? Perhaps
> timer.h is the best place for now, as it already contains the
> next_timer_interrupt() prototype (which probably should be in the #ifdef
> with timer_dyn_reprogram()).

Yes, the above should be enough on all platforms. I believe x86 still uses
two structs, and should be updated to use the interface above. There are
some extra state flags on x86, but even some of those might be
unnecessary now.

It may not be obvious from the mailing list discussions, but really the
remaining problems are to fix the x86 legacy issues with all the timers,
not with the interface.

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