Messages in this thread |  | | Subject | Re: [PATCHSET] Announce: High-res timers, tickless/dyntick and dynamic HZ | | From | Thomas Gleixner <> | | Date | Mon, 19 Jun 2006 22:06:51 +0200 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |