All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Quentin Perret <qperret@google.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	x86@kernel.org, hpa@zytor.com, sudeep.holla@arm.com,
	gregkh@linuxfoundation.org, rafael@kernel.org,
	peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com,
	fweisbec@gmail.com, tkjos@google.com, kernel-team@android.com
Subject: Re: [PATCH 00/14] Modularize schedutil
Date: Fri, 8 May 2020 11:03:59 +0530	[thread overview]
Message-ID: <20200508053359.ul5dbws6vkpdrbef@vireshk-i7> (raw)
In-Reply-To: <20200507181012.29791-1-qperret@google.com>

On 07-05-20, 19:09, Quentin Perret wrote:
> Android is trying very hard to use a single kernel image (commonly
> called Generic Kernel Image, or GKI), closely aligned with mainline, to
> run on all Android devices regardless of the vendor.
> 
> The GKI project intends to not only improve the status quo for Android
> users directly (less fragmentation simplifies updatability), but also
> to benefit upstream by forcing all vendors to agree on one common
> kernel, that we push hard to be aligned with mainline.
> 
> One challenge to implement GKI is to avoid bloating the kernel by
> compiling too many things in, especially given that different devices
> need different things. As such, anything that can be turned into a
> module helps GKI, by offering an alternative to having that component
> built-in. This is true for pretty much anything that can be made
> modular, including drivers as well as other kernel components, such as
> CPUFreq governors.
> 
> Indeed, in practice, Android devices often ship with only one CPUFreq
> governor enabled, and don't require any other that would simply waste
> memory for no benefits. All CPUFreq governors can already be built as
> modules with one notable exception: schedutil. Though popular in
> Android, some devices do not use schedutil, which is why it would be
> preferable to not have it unconditionally built in GKI. This series is
> an attempt to solve this problem, by making schedutil tristate.
> 
> While modularization is usually not something we want to see near the
> scheduler, it appeared to me as I wrote those patches that the
> particular case of schedutil was actually not too bad to implement.
> We already have to support switching governors at run-time, simply
> because userspace is free to do that, so the infrastructure for turning
> sugov on and off dynamically is already there. Loading the code a little
> later doesn't seem to make that a lot worse.
> 
> Patches 01-05 refactor some code to break the few dependencies on
> schedutil being builtin (notably EAS). Patches 06-12 export various
> symbols that schedutil needs when compiled as a module. And finally,
> patches 13-14 finish off the work by making the Kconfig tristate.

IMHO, you have over-broken the patches, like first two could be merged
together and all exports could have been done in a single patch, etc.
i.e. all related or similar changes together...

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

  parent reply	other threads:[~2020-05-08  5:34 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 [this message]
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
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=20200508053359.ul5dbws6vkpdrbef@vireshk-i7 \
    --to=viresh.kumar@linaro.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=rafael@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --cc=tkjos@google.com \
    --cc=vincent.guittot@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.