Re: [PATCHSET] Announce: High-res timers, tickless/dyntick anddynamic HZ

[Thomas Gleixner]

Con,

On Tue, 2006-06-20 at 00:03 +1000, Con Kolivas wrote:
> Dominik donated a lot of code to use the dynticks infrastructure to actually 
> implement the power savings. Just skipping ticks seemed to make very little 
> power difference unless we also used the knowledge from next timer interrupt 
> to know how long we are going to be idle and choose C state transitions 
> accordingly. Each patch is documented at length in the split out
> 
> C-States-1_bm_activity_improvements.patch
> C-States-2_bm_activity_handling_improvement.patch
> C-States-3_accounting_of_sleep_times.patch
> C-States-4_dyn-ticks_tweaks.patch
> 
> http://ck.kolivas.org/patches/dyn-ticks/split-out/

Thanks for pointing that out. We'll look into those tomorrow.

> hrtimer_restart_sched_tick() could use
> struct hrtimer *sched_timer = &cpu_base->sched_timer;
> 
> clockevents_init_next_event() and clockevents_set_next_event() could use
> struct clock_event *nextevt = sources->nextevt;
> 
> > > [...] Also if set_next_event is separated from struct clock_event, the
> > > whole struct looks like a suitable candidate for __read_mostly.
> >
> > You mean ->event_handler()? We can make all clockevent instantiations
> > __read_mostly right now - all of the fields of clock_event are static,
> > even ->event_handler() will change at most once per bootup [when we
> > switch from low-res into high-res mode].

Thanks for the review. 

	tglx


-
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/