Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2805250ybk; Tue, 12 May 2020 08:32:58 -0700 (PDT) X-Google-Smtp-Source: APiQypLW4xvuDaB+hYtOk2k9/Plz610euny4L2l2wViLziAPnB5Frqs27tG/hQWPRevf6EWqEfP1 X-Received: by 2002:aa7:c608:: with SMTP id h8mr18925510edq.232.1589297577783; Tue, 12 May 2020 08:32:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589297577; cv=none; d=google.com; s=arc-20160816; b=0ImM7ONWE1GKjpd9lQnVoX8UJgs84ByjBNhO3LSOjaugFVvIvKDQXbt1/28lWbhLQw BPOtlE0/aDjcuezgRB0HQmdNFvW3YeHf0gXTZa+cN7Dxjid6qiaxX66v7vEklNydW2h3 5JwwGuU1VoZxRsoQSyr+5//JBN2f5T/XdcpZVUufs+MSqWDF0qK//MH8aEXHGznnQw7q wn4dy3g9mUyLJnw8Sx4wOEGY0bLKyLfpnF6EIUfkuehnNlcepILF4DmvSFEKASANDIPm Hf/Z3uAshLv1/2KdRJd4ahz57E6M7HqsglhiQLXBRna3HmFZH4kn56Ardx2vatA1CekU cBlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=RtDSeBieq8eW80YMu3q9EWuFZBKApc+eT4Drp4f7k4U=; b=KwHvopBsFcZa/9ol0Npp8ZlGd7H5t+lMUEHNNR81HI6CgGKX8zV+WRGpNOStqqjfCY xKAHBF9jc5tM37mjFTF5M8TjzxDAO3ultitbvJqIRSFwws3cUbN+Tua4wGV8runZzgur 0SdgW3HPTGYoO+OTHGsR1i/ugphZ+NqExAnOFXjLxtckgZNx+t8ih+tuvWooxzgxiweK WONA3FsQ8JcJzDQxEo03ewyParO8JoHmSTH4ARTFffmfFIT4S9PCIGYb+VKw387yVHRt OnFEm64HnQ27eTFsbKd3N/fMimOGqnL7SdA5am9xEv3EQ0aUmak3+weSfZ5DhEeP79Xe 3MoQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m3si5811678ejr.464.2020.05.12.08.32.34; Tue, 12 May 2020 08:32:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730564AbgELPav (ORCPT + 99 others); Tue, 12 May 2020 11:30:51 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:43928 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727100AbgELPau (ORCPT ); Tue, 12 May 2020 11:30:50 -0400 Received: by mail-oi1-f195.google.com with SMTP id i22so1965341oik.10; Tue, 12 May 2020 08:30:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RtDSeBieq8eW80YMu3q9EWuFZBKApc+eT4Drp4f7k4U=; b=ZMRb4C8Uckd6SUzUgD0bFn9t3kIwURe8GcuNPcmjd0Nw2nJo+U8Vi2IYH2VDdB6Mn6 ZA/ukl5WYtb/DpSI2bbtALpsIodVdXaA0mX6e7+OKpIx0LTHtpap+VmK8gKqB97UapvA WHdr4bvTIIAqvopWVCCKp1e4eZicdF5RTxIwQzv+q59vFtrsxeXrdkzYuygKtUU8vtG4 WpXgsLJJyHFEdF7RFjzzYSsO19bIYdJIiItS1NXONH62+Y6OSU+vo+LdNyJlnPYn/8QX SC3Vx3RaSK/Z/8oq0UfcYDNCmnRf4qnloxGuLZce7rF2CjVMo1MZhX9XXD2gMeV+Zb0o nsBA== X-Gm-Message-State: AGi0PuYD/b0fapC6IIZzeO7aG0aTkqx8XD0k7tqzm8p19QP3TLvLGMH1 FtPzXUsgr/z3hIIfegv/D3q7oZZqWy4VYT3jvbQ= X-Received: by 2002:aca:4254:: with SMTP id p81mr1720404oia.68.1589297448303; Tue, 12 May 2020 08:30:48 -0700 (PDT) MIME-Version: 1.0 References: <20200508111612.GA252673@google.com> <20200508113141.GB5298@hirez.programming.kicks-ass.net> <20200508130507.GA10541@google.com> <20200511090049.GA229633@google.com> <20200512092102.GA16151@google.com> <20200512135813.GA101124@google.com> <20200512151120.GB101124@google.com> In-Reply-To: <20200512151120.GB101124@google.com> From: "Rafael J. Wysocki" Date: Tue, 12 May 2020 17:30:36 +0200 Message-ID: Subject: Re: [PATCH 00/14] Modularize schedutil To: Quentin Perret Cc: "Rafael J. Wysocki" , Peter Zijlstra , Greg KH , Linux Kernel Mailing List , Linux PM , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "the arch/x86 maintainers" , "H. Peter Anvin" , Sudeep Holla , Viresh Kumar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Benjamin Segall , Mel Gorman , "Luis R. Rodriguez" , Kees Cook , Iurii Zaikin , Frederic Weisbecker , Todd Kjos , "Cc: Android Kernel" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 12, 2020 at 5:11 PM Quentin Perret 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!