[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230907115307.GD10955@noisy.programming.kicks-ass.net>
Date: Thu, 7 Sep 2023 13:53:07 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Lukasz Luba <lukasz.luba@....com>
Cc: Qais Yousef <qyousef@...alina.io>, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, "Rafael J. Wysocki" <rafael@...nel.org>,
Ingo Molnar <mingo@...nel.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [RFC PATCH 0/7] sched: cpufreq: Remove magic margins
On Thu, Sep 07, 2023 at 08:48:08AM +0100, Lukasz Luba wrote:
> > Hehe. That's because they're not really periodic ;-)
>
> They are periodic in a sense, they wake up every 16ms, but sometimes
> they have more work. It depends what is currently going in the game
> and/or sometimes the data locality (might not be in cache).
>
> Although, that's for games, other workloads like youtube play or this
> one 'Yahoo browser' (from your example) are more 'predictable' (after
> the start up period). And I really like the potential energy saving
> there :)
So everything media is fundamentally periodic, you're hard tied to the
framerate / audio-buffer size etc..
Also note that the traditional periodic task model from the real-time
community has the notion of WCET, which completely covers this
fluctuation in frame-to-frame work, it only considers the absolute worst
case.
Now, practically, that stinks, esp. when you care about batteries, but
it does not mean these tasks are not periodic.
Many extentions to the periodic task model are possible, including
things like average runtime with bursts etc.. all have their trade-offs.
Powered by blists - more mailing lists