Messages in this thread | | | Date | Mon, 29 Aug 2022 15:31:05 +0000 | From | Quentin Perret <> | Subject | Re: [RFC PATCH 1/1] sched/pelt: Introduce PELT multiplier |
| |
On Monday 29 Aug 2022 at 16:34:39 (+0200), Peter Zijlstra wrote: > On Mon, Aug 29, 2022 at 02:23:17PM +0000, Quentin Perret wrote: > > FWIW. Typically a larger half-life will be fine with predictable > > workloads with little inputs from users (e.g. fullscreen video playback) > > while a lower one can be preferred in highly interactive cases (games, > > As per always; consider the combined workload.
That's the problem of whoever is going to decide which HL should be used, which would all fall in userspace policy land. And yes that userspace agent would have to know quite a bit about what is going on in the system to make 'sane' decisions, but that is the case in Android.
The fact that choosing the right HL for a combined workload is hard (that userspace agent might want to just default to a safe value?) doesn't mean there is no value in other cases though...
I mean, if we agree that tuning the PELT HL makes sense at all (even as a cmdling arg, or sched_feat or whatever), there is only one small step to say the right PELT HL should indeed depend on the workload you're currently running (especially with _vastly_ different usage patterns seen in mobile).
> > ...). The transient state is fun to reason about, but it really > > shouldn't be too common AFAIK. > > Once you give away control there is no taking it back, and userspace > *will* do stupid things and expect unicorns.
Sure. If you do stupid, at some point you get(/deserve) what you asked for... We could perhaps rate-limit changes or something if we want to make that clear?
| |