Messages in this thread | | | Date | Wed, 9 Nov 2022 15:18:52 +0000 | Subject | Re: [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime | From | Lukasz Luba <> |
| |
Hi Peter,
On 11/7/22 13:41, Peter Zijlstra wrote: > On Thu, Sep 29, 2022 at 03:41:47PM +0100, Kajetan Puchalski wrote: > >> Based on all the tests we've seen, jankbench or otherwise, the >> improvement can mainly be attributed to the faster ramp up of frequency >> caused by the shorter PELT window while using schedutil. > > Would something terrible like the below help some? > > If not, I suppose it could be modified to take the current state as > history. But basically it runs a faster pelt sum along side the regular > signal just for ramping up the frequency.
[snip]
> + > + rcu_read_lock(); > + curr = rcu_dereference(rq->curr); > + if (likely(curr->sched_class == &fair_sched_class)) { > + u64 runtime = curr->se.sum_exec_runtime - curr->se.exec_start; > + util = max_t(unsigned long, util, > + faster_est_approx(runtime * 2));
That's a really nice hack :)
I wonder why we end up in such situation on Android. Maybe there is a different solution? Maybe shorter tick (then also align PELT Half-Life)?
The problem is mostly in those high-FPS phones. You know, we now have phones with 144Hz displays and even games > 100FPS (which wasn't the case a few years ago when we invested a lot of effort into this PELT+EAS). We also have a lot faster CPUs (~2x in 3-4 years).
IMO those games (and OS mechanisms assisting them) would have different needs probably (if they do this 'soft-real-time simulations' with such high granularity ~120/s -> every ~8ms).
IMO one old setting might not fit well into this: 4ms tick (which is the Android use case), which then implies scheduler min granularity, which we also align with the y^32 PELT. Is this a correct chain of thinking?
Would it make sense to ask Android phone vendors to experiment with 1ms tick (w/ aligned PELT HL)? With that change, there might be some power spikes issues, though.
Regards, Lukasz
| |