Message ID | 20230509122246.1702397-1-lukasz.luba@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | Add basic tracing for uclamp and schedutil | expand |
Hi Rafael, On 5/9/23 13:22, Lukasz Luba wrote: > Hi all, > > The task scheduler feature: Uclamp, begins to take off. To better understand > the dynamics in the task scheduler and CPU frequency requests we need some > better tracing. > In schedutil (cpufreq governor) we allow to enter the scheduler > and make the frequency change. Although, there is some limit in regards to how > often this can happen. That min period is provided by the cpufreq driver. > Thus, some of the cpufreq requests might be filter out and the frequency won't > be changed (hopefuly will be set a bit later). We would like to know about > those situations, especially in context of the user-space hints made via > Uclamp for particular tasks. > This patch set aims to add base for our toolkits and post-processing trace > analyzes. > > Changelog: > v2: > - solved the issue from CI build warning, dropped schedutil.h and re-used > the sched.h which is available in build_utility.c where cpufreq_schedutil.c > is included > - added tag for the last patch 3/3 for the CI robot helping hend > - re-based on top of v6.4-rc1 > v1: > - implementation can be found here [1] > I was going to gently ping you, while I've realized that you are not on CC list :( I don't know what happened, my apologies. Shell I resend this patch set so you can have it in a proper way in your mailbox? Could you have a look at this, please? This is getting more attention, since in Android we have a daemon which can now communicate with the kernel and send those Uclamp values on behalf of an unprivileged app. Regards, Lukasz
Hi Lukasz, On Mon, May 22, 2023 at 3:38 PM Lukasz Luba <lukasz.luba@arm.com> wrote: > > Hi Rafael, > > > > On 5/9/23 13:22, Lukasz Luba wrote: > > Hi all, > > > > The task scheduler feature: Uclamp, begins to take off. To better understand > > the dynamics in the task scheduler and CPU frequency requests we need some > > better tracing. > > In schedutil (cpufreq governor) we allow to enter the scheduler > > and make the frequency change. Although, there is some limit in regards to how > > often this can happen. That min period is provided by the cpufreq driver. > > Thus, some of the cpufreq requests might be filter out and the frequency won't > > be changed (hopefuly will be set a bit later). We would like to know about > > those situations, especially in context of the user-space hints made via > > Uclamp for particular tasks. > > This patch set aims to add base for our toolkits and post-processing trace > > analyzes. > > > Changelog: > > v2: > > - solved the issue from CI build warning, dropped schedutil.h and re-used > > the sched.h which is available in build_utility.c where cpufreq_schedutil.c > > is included > > - added tag for the last patch 3/3 for the CI robot helping hend > > - re-based on top of v6.4-rc1 > > v1: > > - implementation can be found here [1] > > > > I was going to gently ping you, while I've realized that you > are not on CC list :( I don't know what happened, my apologies. No worries. > Shell I resend this patch set so you can have it in a proper way > in your mailbox? Well, for schedutil you should also CC linux-pm (done now), so please resend it. > Could you have a look at this, please? I could, but if I'm to reply, it will be much more convenient for me if it is there in my inbox. > This is getting more attention, since in Android we have a > daemon which can now communicate with the kernel and send > those Uclamp values on behalf of an unprivileged app.
On 5/22/23 15:40, Rafael J. Wysocki wrote: > Hi Lukasz, > > On Mon, May 22, 2023 at 3:38 PM Lukasz Luba <lukasz.luba@arm.com> wrote: >> >> Hi Rafael, >> >> >> >> On 5/9/23 13:22, Lukasz Luba wrote: >>> Hi all, >>> >>> The task scheduler feature: Uclamp, begins to take off. To better understand >>> the dynamics in the task scheduler and CPU frequency requests we need some >>> better tracing. >>> In schedutil (cpufreq governor) we allow to enter the scheduler >>> and make the frequency change. Although, there is some limit in regards to how >>> often this can happen. That min period is provided by the cpufreq driver. >>> Thus, some of the cpufreq requests might be filter out and the frequency won't >>> be changed (hopefuly will be set a bit later). We would like to know about >>> those situations, especially in context of the user-space hints made via >>> Uclamp for particular tasks. >>> This patch set aims to add base for our toolkits and post-processing trace >>> analyzes. >> >>> Changelog: >>> v2: >>> - solved the issue from CI build warning, dropped schedutil.h and re-used >>> the sched.h which is available in build_utility.c where cpufreq_schedutil.c >>> is included >>> - added tag for the last patch 3/3 for the CI robot helping hend >>> - re-based on top of v6.4-rc1 >>> v1: >>> - implementation can be found here [1] >>> >> >> I was going to gently ping you, while I've realized that you >> are not on CC list :( I don't know what happened, my apologies. > > No worries. > >> Shell I resend this patch set so you can have it in a proper way >> in your mailbox? > > Well, for schedutil you should also CC linux-pm (done now), so please resend it. > >> Could you have a look at this, please? > > I could, but if I'm to reply, it will be much more convenient for me > if it is there in my inbox. > Thanks Rafael for instant response. I'll resend it with the proper CC list this time.