linux-kernel - Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200624175236.nblndmg6dfq2vr2u@e107158-lin.cambridge.arm.com>
Date:   Wed, 24 Jun 2020 18:52:38 +0100
From:   Qais Yousef <qais.yousef@....com>
To:     Joel Fernandes <joelaf@...gle.com>
Cc:     Doug Anderson <dianders@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Benson Leung <bleung@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        hsinyi@...omium.org, Nicolas Boichat <drinkcat@...omium.org>,
        Gwendal Grignou <gwendal@...omium.org>,
        Quentin Perret <qperret@...gle.com>, ctheegal@...eaurora.org,
        Guenter Roeck <groeck@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump
 cpu freq

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