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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]