From: Qais Yousef <qyousef@layalina.io>
To: Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
mingo@redhat.com, juri.lelli@redhat.com,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
vschneid@redhat.com, viresh.kumar@linaro.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
lukasz.luba@arm.com, wyes.karny@amd.com, beata.michalska@arm.com
Subject: Re: [PATCH v3 0/2] Rework interface between scheduler and schedutil governor
Date: Tue, 14 Nov 2023 21:13:32 +0000 [thread overview]
Message-ID: <20231114211332.c3yhmfm7vxgysi72@airbuntu> (raw)
In-Reply-To: <20231116143450.GF8262@noisy.programming.kicks-ass.net>
On 11/16/23 15:34, Peter Zijlstra wrote:
> On Mon, Nov 06, 2023 at 04:05:40PM +0100, Rafael J. Wysocki wrote:
> > On Fri, Nov 3, 2023 at 2:18 PM Vincent Guittot
> > <vincent.guittot@linaro.org> wrote:
> > >
> > > Following the discussion with Qais [1] about how to handle uclamp
> > > requirements and after syncing with him, we agreed that I should move
> > > forward on the patchset to rework the interface between scheduler and
> > > schedutil governor to provide more information to the latter. Scheduler
> > > (and EAS in particular) doesn't need anymore to guess estimate which
> > > headroom the governor wants to apply and will directly ask for the target
> > > freq. Then the governor directly gets the actual utilization and new
> > > minimum and maximum boundaries to select this target frequency and
> > > doesn't have to deal anymore with scheduler internals like uclamp when
> > > including iowait boost.
Thanks a lot for taking over Vincent and helping with this! And sorry for
delayed review, was out travelling between holiday and LPC so haven't caught up
with the list properly yet..
Beside the comments on patch 1, it looks good to me. Do we want to generalize
the way the interface is called though so that scheduler is not tightly coupled
to schedutil? Speaking with Intel folks in LPC, it seemed they rely on firmware
to make a lot of decision and if we further generalize how the interface is
called (I think we need a new cpufreq wrapper akin to cpufreq_update_util()) to
allow governors to hook into it and do their own thing. This could allow them
to use uclamp and these min/max perf hints.
But I haven't thought this fully through. So something to consider separately
anyway to not hold this up unnecessarily. Maybe we do want to keep schedutil
tightly integrated and get people to switch to schedutil instead..
> > >
> > > [1] https://lore.kernel.org/lkml/CAKfTPtA5JqNCauG-rP3wGfq+p8EEVx9Tvwj6ksM3SYCwRmfCTg@mail.gmail.com/
> > >
> > > Changes since v2:
> > > - remove useless target variable
> > >
> > > Changes since v1:
> > > - fix a bug (always set max even when returning early)
> > > - fix typos
> > >
> > > Vincent Guittot (2):
> > > sched/schedutil: Rework performance estimation
> > > sched/schedutil: Rework iowait boost
> > >
> > > include/linux/energy_model.h | 1 -
> > > kernel/sched/core.c | 82 ++++++++++++-------------------
> > > kernel/sched/cpufreq_schedutil.c | 69 ++++++++++++++++----------
> > > kernel/sched/fair.c | 22 +++++++--
> > > kernel/sched/sched.h | 84 +++-----------------------------
> > > 5 files changed, 100 insertions(+), 158 deletions(-)
> > >
> > > --
> >
> > For the schedutil changes in the series:
> >
> > Acked-by: Rafael J. Wysocki <rafael@kernel.org>
> >
> > and I'm assuming this series to be targeted at sched.
>
> Sure, I'll go queue it. Thanks!
Sorry for being late. If this wasn't queued already I think worth waiting to
iron out some comments on patch 1 first.
Thanks!
--
Qais Yousef
prev parent reply other threads:[~2023-11-21 17:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-03 13:18 [PATCH v3 0/2] Rework interface between scheduler and schedutil governor Vincent Guittot
2023-11-03 13:18 ` [PATCH v3 1/2] sched/schedutil: Rework performance estimation Vincent Guittot
2023-11-14 20:54 ` Qais Yousef
2023-11-22 7:38 ` Vincent Guittot
2023-11-21 21:17 ` Qais Yousef
2023-11-23 7:47 ` Vincent Guittot
2023-11-21 22:09 ` Qais Yousef
2023-11-23 13:32 ` Vincent Guittot
2023-11-21 22:31 ` Qais Yousef
2023-11-16 13:19 ` Lukasz Luba
2023-11-03 13:18 ` [PATCH v3 2/2] sched/schedutil: Rework iowait boost Vincent Guittot
2023-11-14 20:59 ` Qais Yousef
2023-11-06 15:05 ` [PATCH v3 0/2] Rework interface between scheduler and schedutil governor Rafael J. Wysocki
2023-11-16 14:34 ` Peter Zijlstra
2023-11-14 21:13 ` Qais Yousef [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231114211332.c3yhmfm7vxgysi72@airbuntu \
--to=qyousef@layalina.io \
--cc=beata.michalska@arm.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=vschneid@redhat.com \
--cc=wyes.karny@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox