Randy Dunlap wrote: > Hi, > > I was looking into making mod_timer() be somewhat imprecise in when > it sets the target timer to fire. The goal of this is saving power, > as measured indirectly by powertop wakeups per second. > > There is already a notion of slack (or delta) time in > kernel/hrtimer.c::hrtimer_start_range_ns() and in > kernel/hrtimer.c::schedule_hrtimeout_range(), so maybe I'm attempting > to modify the incorrect function, or maybe another interface function > is needed for this. (?) > > I did find one user of hrtimer_start_range_ns() (in fs/ubifs/io.c). > Is that the preferred interface to use when imprecise timers are > acceptable? > > > Results of this patch (that is below) are inconclusive IMO. > I ran multiple runs of a short database test on an HP ProLiant BladeCenter > (BL685c G1), which also has firmware for power usage measurements. > > averages: > kernel 2.6.31 unpatched: 159 Watts, 302.7 wakeups/second > kernel 2.6.31 + patch(N=9): 161 Watts, 291.1 wakeups/second > kernel 2.6.31 + patch(N=19): 163 Watts, 316.3 wakeups/second > kernel 2.6.31 + patch(N=99): 161 Watts, 284 wakeups/second > > > Any comments or suggestions?
from the numbers you posted, I don't think you have a statistical significant difference either way... but, more importantly, I wonder if the N numbers you are trying to delay timers are not too short in order for the system to actually draw much less power. IOW given your random load, C-state tables you might not expect to see that much at all. Auke _______________________________________________ Discuss mailing list [email protected] http://lists.lesswatts.org/listinfo/discuss
