All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Quentin Perret <qperret@google.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Benjamin Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Iurii Zaikin <yzaikin@google.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Todd Kjos <tkjos@google.com>,
	"Cc: Android Kernel" <kernel-team@android.com>
Subject: Re: [PATCH 00/14] Modularize schedutil
Date: Tue, 12 May 2020 17:30:36 +0200	[thread overview]
Message-ID: <CAJZ5v0inoge=nWQtv-rU_ReQUMZA5w-PZXuSpHHj1UHn-S7aSA@mail.gmail.com> (raw)
In-Reply-To: <20200512151120.GB101124@google.com>

On Tue, May 12, 2020 at 5:11 PM Quentin Perret <qperret@google.com> wrote:
>
> On Tuesday 12 May 2020 at 16:08:56 (+0200), Rafael J. Wysocki wrote:
> > If some piece of kernel code is modular, it still needs to be build.
> > The difference is when and how it gets loaded, so can you possibly
> > elaborate here?
>
> Sure thing, sorry if that wasn't clear.

No worries.

> The end goal with GKI is the following: Google will release a single
> binary kernel image (signed, etc etc) that all devices using a given
> Android version will be required to use. That image is however going to
> be only for the core of the kernel (no drivers or anything of the sort).
> Vendors and OEMs, on their end, will be responsible to build and ship
> GKI-compatible modules for their respective devices. So, Android devices
> will eventually ship with a Google-issued GKI, plus a bunch of
> vendor-provided modules loaded during boot.

If that is the case, then I absolutely think that schedutil should be
part of the GKI.

Moreover, that would have been my opinion even if it had been modular
in the first place.

> This is a significant shift from the current model where vendors
> completely own the kernel, and are largely free to use the kernel config
> they want. Today, those who don't use schedutil are free to turn the
> config off, for example.

So why is this regarded as a good thing?

> But GKI changes that. The 'core' GKI config is effectively imposed to
> the entire ecosystem. As of now, because it is 'bool' we have no choice
> but to compile schedutil in the core GKI as some (most) partners use it.
> But as you can imagine, that is not the preferred option of those who
> _don't_ use schedutil.

OTOH, it may as well be an incentive for them to switch over and
report problems with it that they see.

I absolutely would like to make schedutil the clearly preferred option
and IMO avoiding to use it, especially for non-technical reasons,
should be clearly less attractive.

> Modularizing avoids any potential friction since
> the vendors who want to use it will be able load the module, and the
> others will simply not. That really is the reason for that series.

If the long-term target is for everyone to use schedutil, then I don't
quite see why making it easy to not include it in one's system is
going to help.

> Then there is an important question: why should upstream care about all
> that stuff? That's obviously debatable, but my biased opinion is that
> GKI is a good thing(TM). It's our opportunity to put some order in the
> android ecosystem and to reduce the delta with mainline. That'll
> definitely take time, and there will be Android-specific churn in GKI in
> the beginning, but we'd like to keep that as small as possible, and to
> converge to 0 looking forwards.

That's a good goal, but I'm not sure if the least resistance path to
it is the right one. :-)

Cheers!

  reply	other threads:[~2020-05-12 15:30 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07 18:09 [PATCH 00/14] Modularize schedutil Quentin Perret
2020-05-07 18:09 ` [PATCH 01/14] sched: Provide sched_set_deadline() Quentin Perret
2020-05-07 18:10 ` [PATCH 02/14] sched: cpufreq: Use sched_set_deadline() from sugov Quentin Perret
2020-05-07 18:10 ` [PATCH 03/14] sched: cpufreq: Introduce 'want_eas' governor flag Quentin Perret
2020-05-07 18:10 ` [PATCH 04/14] sched: cpufreq: Move sched_cpufreq_governor_change() Quentin Perret
2020-05-08  5:35   ` Pavan Kondeti
2020-05-08 13:18     ` Quentin Perret
2020-05-07 18:10 ` [PATCH 05/14] sched: cpufreq: Move schedutil_cpu_util() Quentin Perret
2020-05-07 18:10 ` [PATCH 06/14] arch_topology: Export cpu_scale per-cpu array Quentin Perret
2020-05-07 18:10 ` [PATCH 07/14] kthread: Export kthread_bind_mask() Quentin Perret
2020-05-07 18:10 ` [PATCH 08/14] sched/core: Export runqueues per-cpu array Quentin Perret
2020-05-08  8:07   ` Peter Zijlstra
2020-05-08 10:04     ` Quentin Perret
2020-05-07 18:10 ` [PATCH 09/14] sched/cpufreq: Export cpufreq_this_cpu_can_update() Quentin Perret
2020-05-07 18:10 ` [PATCH 10/14] sched/fair: Export cpu_util_freq() Quentin Perret
2020-05-07 18:10 ` [PATCH 11/14] tick/sched: Export tick_nohz_get_idle_calls_cpu Quentin Perret
2020-05-07 18:10 ` [PATCH 12/14] x86: Export arch_scale_freq_key Quentin Perret
2020-05-07 18:10 ` [PATCH 13/14] sched: cpufreq: Use IS_ENABLED() for schedutil Quentin Perret
2020-05-08  5:30   ` Pavan Kondeti
2020-05-08 13:21     ` Quentin Perret
2020-05-09  2:43       ` Pavan Kondeti
2020-05-07 18:10 ` [PATCH 14/14] sched: cpufreq: Modularize schedutil Quentin Perret
2020-05-07 21:34 ` [PATCH 00/14] " Valentin Schneider
2020-05-08 13:15   ` Quentin Perret
2020-05-08 14:52     ` Valentin Schneider
2020-05-08  5:33 ` Viresh Kumar
2020-05-08 13:18   ` Quentin Perret
2020-05-08  8:11 ` Peter Zijlstra
2020-05-08 10:37   ` Greg KH
2020-05-08 11:16     ` Quentin Perret
2020-05-08 11:31       ` Peter Zijlstra
2020-05-08 13:05         ` Quentin Perret
2020-05-08 13:40           ` Rafael J. Wysocki
2020-05-11  9:00             ` Quentin Perret
2020-05-11 15:26               ` Rafael J. Wysocki
2020-05-12  9:21                 ` Quentin Perret
2020-05-12 10:25                   ` Rafael J. Wysocki
2020-05-12 13:58                     ` Quentin Perret
2020-05-12 14:08                       ` Rafael J. Wysocki
2020-05-12 15:11                         ` Quentin Perret
2020-05-12 15:30                           ` Rafael J. Wysocki [this message]
2020-05-12 15:49                             ` Joel Fernandes
2020-05-13  8:57                               ` Quentin Perret
2020-05-12 16:26                             ` Quentin Perret
2020-05-12 17:30                               ` Rafael J. Wysocki
2020-05-13  9:41                                 ` Quentin Perret
2020-05-13 10:02                                   ` Greg KH
2020-05-13 10:06                                     ` Quentin Perret
2020-05-13 10:24                                       ` Greg KH
2020-05-08 14:09           ` Peter Zijlstra
2020-05-11  9:12             ` Quentin Perret
2020-05-08 11:26     ` Peter Zijlstra
2020-05-11  5:21       ` Viresh Kumar

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='CAJZ5v0inoge=nWQtv-rU_ReQUMZA5w-PZXuSpHHj1UHn-S7aSA@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=bp@alien8.de \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=juri.lelli@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=rostedt@goodmis.org \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --cc=tkjos@google.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=x86@kernel.org \
    --cc=yzaikin@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.