Messages in this thread | | | Date | Tue, 8 Nov 2022 19:48:43 +0000 | From | Qais Yousef <> | Subject | Re: [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime |
| |
On 11/07/22 14: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.
A bit of a tangent, but this reminded me of this old patch:
https://lore.kernel.org/lkml/1623855954-6970-1-git-send-email-yt.chang@mediatek.com/
I think we have a bit too many moving cogs that might be creating undesired compound effect.
Should we consider removing margins in favour of improving util ramp up/down? (whether via util_est or pelt hf).
Only worry is lower end devices; but it seems to me better improve util response and get rid of these magic numbers - if we can. Having the ability to adjust them at runtime will help defer the trade-offs to sys admins.
Thanks
-- Qais Yousef
| |