From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F0B6C54E4A for ; Tue, 12 May 2020 14:09:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2D78E20722 for ; Tue, 12 May 2020 14:09:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589292552; bh=XlLg66om9qePZXeASi6fwsBTwuJ8dfQeSI2ucy4Tfaw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=xU++5i2Q8jdoiP7paBYBBlf6t1iISfgC/aZKM32MSSHtC4bSPb8qeKySGL3hEJf4t kcX3r4QDZ2ZmeB7X2duvZBxKYssXqxL4K7LyhN/68/6M87R47Der/OF8ASUK6hvlml tkpbjL1O9E2kgLeK112ENebxYZHGq7CMxPOylOeo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730168AbgELOJL (ORCPT ); Tue, 12 May 2020 10:09:11 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:43257 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727859AbgELOJK (ORCPT ); Tue, 12 May 2020 10:09:10 -0400 Received: by mail-ot1-f67.google.com with SMTP id a68so2069586otb.10; Tue, 12 May 2020 07:09:08 -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=XlLg66om9qePZXeASi6fwsBTwuJ8dfQeSI2ucy4Tfaw=; b=i9SaClcqX8A0nYi/p1xB3lptVwUFTpWevNUsQwd2d2M4MvDWFweIyh/QEZIUpUmiQQ O6RQcNqFwDc9nG2JLtjIEcQSTwZGHtekKXOz37LH9VXKBZoJV0gxnyxIExW6ABCJkJHb jYmh+DelMCS0UdilEcr2DSlY4HaQX+n4q5fZTA3C5gDjAVg/ZzFscZjJc4RSm34Oj0G+ mWz0mYyTVLg5r2KgqF8Ze4LCWqJXJRYq15ghnDD4r1FATqDasDTvCeTWfdTqfS3yDPN4 UotzLWAVoJMkXdDsFSlEEnUX/0+8vc/mKM7PzxF3aqIqJp9rsko9wcvqFdPmBJEAYV5I VT9g== X-Gm-Message-State: AGi0Pubvq3rpq9Tlky6liYyQksOqOmNRE7F4Gh1BgHQ8/70nQtmno4Hv Yv7MLvVRXUPvEu1QlHEQkwMY9nWjjoXuKzXuGWo= X-Google-Smtp-Source: APiQypLSjiwX7PHp/boQvrrT9A2LLBsxN4GgnX7T8BCX5CQ4Qti5EIdMckwEZSBnSBOrvY/RjAqINo6HDSkgtHeujTs= X-Received: by 2002:a9d:6356:: with SMTP id y22mr3701328otk.167.1589292548150; Tue, 12 May 2020 07:09:08 -0700 (PDT) MIME-Version: 1.0 References: <20200508081128.GM5298@hirez.programming.kicks-ass.net> <20200508103721.GA3860390@kroah.com> <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> In-Reply-To: <20200512135813.GA101124@google.com> From: "Rafael J. Wysocki" Date: Tue, 12 May 2020 16:08:56 +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 3:58 PM Quentin Perret wrote: > > On Tuesday 12 May 2020 at 12:25:17 (+0200), Rafael J. Wysocki wrote: > > Still, IMO it would be fair to say that if uclamps are used, schedutil > > is very likely to be preferred. > > > > Kconfig can be made select schedutil when enabling uclamps or similar > > to express that preference. > > Right, fair enough. Making schedutil default to y when uclamp is > compiled in should do the trick (and avoid using 'select'). Would that > work for you? I think so. > > What you are proposing is basically to add complexity and the reason > > for doing that seems to be convenience (and that's not the users' > > convenience for that matter) which is not really super-convincing. > > Forcing our users to build in their products something they don't want > to use tends to be a very real problem for what we're trying to achieve, > so it's certainly not just convenience from our perspective. I can > understand that yours might be different, though. I would like to understand the nature of the problem here. 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? Cheers!