[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <03f3bdd8-d3c1-448c-ba46-7be2289d75ae@arm.com>
Date: Wed, 10 Jul 2024 18:22:40 +0200
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: Vincent Guittot <vincent.guittot@...aro.org>,
Qais Yousef <qyousef@...alina.io>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>, Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, Juri Lelli <juri.lelli@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>,
Mel Gorman <mgorman@...e.de>, Daniel Bristot de Oliveira
<bristot@...hat.com>, Valentin Schneider <vschneid@...hat.com>,
Christian Loehle <christian.loehle@....com>,
Hongyan Xia <hongyan.xia2@....com>, John Stultz <jstultz@...gle.com>,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6] sched: Consolidate cpufreq updates
On 09/07/2024 09:48, Vincent Guittot wrote:
> On Wed, 19 Jun 2024 at 22:14, Qais Yousef <qyousef@...alina.io> wrote:
[...]
>> @@ -811,7 +818,14 @@ int __sched_setscheduler(struct task_struct *p,
>> if (running)
>> set_next_task(rq, p);
>>
>> - check_class_changed(rq, p, prev_class, oldprio);
>> + update_cpufreq |= check_class_changed(rq, p, prev_class, oldprio);
>> +
>> + /*
>> + * Changing class or uclamp value implies requiring to send cpufreq
>> + * update.
>> + */
>> + if (update_cpufreq && running)
>
> Why running ? it should be queued as we are max aggregating
Also wondering ... IMHO, this has been discussed in v4 already:
https://lkml.kernel.org/r/20240529011144.smuq6dbaxvulxy4e@airbuntu
[...]
Powered by blists - more mailing lists