On Mon, 14 Dec 2015 16:07:59 +0000 Juri Lelli <juri.le...@arm.com> wrote: [...] > > I agree that if the WCET is far from reality, we will underestimate > > available capacity for CFS. Have you got some use case in mind which > > overestimates the WCET ? > > I guess simply the fact that one task can be admitted to the system, > but then in practice sleep, waiting from some event to happen. My favourite example (since 1998 :) is a video player (but every task processing compressed video should work as an example): there is a noticeable difference between the time needed to process large I frames with a lot of movement (that is about the WCET) and the time needed to process small B frames with not much movement. And if we want to avoid too much jitter in the video playback we have to allocate the runtime based on the maximum time needed to process a video frame.
> > If we can't rely on this parameters to evaluate the amount of > > capacity used by deadline scheduler on a core, this will imply that > > we can't also use it for requesting capacity to cpufreq and we > > should fallback on a monitoring mechanism which reacts to a change > > instead of anticipating it. > > > > There is at least one way in the middle: use utilization of active > servers (as I think Luca was already mentioning). This solution should > remove some of the pessimism, but still be safe for our needs. If you track the active utilisation as done by the GRUB algorithm ( http://retis.sssup.it/~lipari/papers/lipariBaruah2000.pdf ) and by my patches, you can remove _all_ the pessimism :) Luca -- 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/
