On Mon, Dec 14, 2015 at 10:31:13PM +0100, Luca Abeni wrote: > > There 'might' be smart pants ways around this, where you run part of > > the execution at lower speed and switch to a higher speed to 'catch' > > up if you exceed some boundary, such that, on average, you run at the > > same speed the WCET mandates, but I'm not sure that's worth it. > > Juri/Luca might know.
> Some previous works (see for example > https://www.researchgate.net/profile/Giuseppe_Lipari/publication/220800940_Using_resource_reservation_techniques_for_power-aware_scheduling/links/09e41513639b2703fc000000.pdf > ) investigated the usage of the "active utilisation" for switching the > CPU frequency. This "active utilisation tracking" mechanism is the same > I mentioned in the previous email, and implemented here: > https://github.com/lucabe72/linux-reclaiming/commit/49fc786a1c453148625f064fa38ea538470df55b > . I have stuck the various PDFs and commits you've linked into my todo list ;-) Thanks! > I suspect the "inactive timer" I used to decrease the utilisation at > the so called 0-lag time might be problematic, but I did not find any > way to implement (or approximate) the active utilisation tracking > without this timer... Anyway, if there is interest I am willing to > adapt/rework/modify my patches as needed. So I remember something else from the BFQ code, which also had to track entries for the 0-lag stuff, and I just had a quick peek at that code again. And what they appear to do is keep inactive entries with a lag deficit in a separate tree (the idle tree). And every time they update the vtime, they also push fwd the idle tree and expire entries on that. Or that is what I can make of it in a quick few minutes staring at that code -- look for bfq_forget_idle(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/