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;
Date:   Wed, 24 Jun 2020 18:52:38 +0100
From:   Qais Yousef <qais.yousef@arm.com>
To:     Joel Fernandes <joelaf@google.com>
Cc:     Doug Anderson <dianders@chromium.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Benson Leung <bleung@chromium.org>,
        Enric Balletbo i Serra <enric.balletbo@collabora.com>,
        hsinyi@chromium.org, Nicolas Boichat <drinkcat@chromium.org>,
        Gwendal Grignou <gwendal@chromium.org>,
        Quentin Perret <qperret@google.com>, ctheegal@codeaurora.org,
        Guenter Roeck <groeck@chromium.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump
 cpu freq
Message-ID: <20200624175236.nblndmg6dfq2vr2u@e107158-lin.cambridge.arm.com>
References: <20200610151818.1.I666ecd9c6f3c6405bd75831a21001b8109b6438c@changeid>
 <20200612125250.7bwjfnxhurdf5bwj@e107158-lin.cambridge.arm.com>
 <CAD=FV=WuYZRO=sv4ODr0SFk0gTtvCW0dNQXbFGrBDqRgjYv-jA@mail.gmail.com>
 <20200619153851.vigshoae3ahiy63x@e107158-lin.cambridge.arm.com>
 <CAD=FV=XursDFUWL=aGUwFgXc4BugUMdT5e+Fwwo5w2gReCjUaQ@mail.gmail.com>
 <20200623164021.lcrnwpli7wdlsn5i@e107158-lin.cambridge.arm.com>
 <CAJWu+ooXdgqSGisZXnHBtYLo9oQBiaNR=HhKseBN+YFGz-L6Xg@mail.gmail.com>
 <20200624165500.idrugfgplqgi654v@e107158-lin.cambridge.arm.com>
 <CAJWu+oqHUq6fvkfRgAx4qx8x1dm-J-h6moeVskCU3gkRybCPqQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAJWu+oqHUq6fvkfRgAx4qx8x1dm-J-h6moeVskCU3gkRybCPqQ@mail.gmail.com>
User-Agent: NeoMutt/20171215
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 06/24/20 13:35, Joel Fernandes wrote:

[...]

> > Doing the in-kernel opt-out via API should be fine, I think. But this will
> > need to be discussed in the wider circle. It will already clash with this for
> > example
> >
> > https://lore.kernel.org/lkml/20200619172011.5810-1-qais.yousef@arm.com/
> 
> Have not yet looked closer at that patch, but are you saying this
> patch clashes with that work? Sorry I am operating on 2 hours of sleep
> here.

The series is an optimization to remove the uclamp overhead from the scheduler
fastpath until the userspace uses it. It introduces a static key that is
disabled by default and will cause uclamp logic not to execute in the fast
path. Once the userspace starts using util clamp, which we detect by either

	1. Changing uclamp value of a task with sched_setattr()
	2. Modifying the default sysctl_sched_util_clamp_{min, max}
	3. Modifying the default cpu.uclamp.{min, max} value in cgroup

If we start having in-kernel users changing uclamp value this means drivers
will cause the system to opt-in into uclamp automatically even if the
userspace doesn't actually use it.

I think we can solve this by providing a special API to opt-out safely. Which
is the right thing to do anyway even if we didn't have this clash.

Hope this makes sense.

Cheers

--
Qais Yousef