[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG+v+Kaa6Rfza_WewMw4K=vRTrt9UhRXp7G3XVi9cd_LvZkVEQ@mail.gmail.com>
Date: Wed, 18 May 2022 16:55:09 +0100
From: "Feiran Zheng ." <fam.zheng@...edance.com>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
zhouchengming@...edance.com, fam@...hon.net,
Mel Gorman <mgorman@...e.de>, Ingo Molnar <mingo@...hat.com>,
songmuchun@...edance.com, Juri Lelli <juri.lelli@...hat.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Cristian Marussi <cristian.marussi@....com>
Subject: Re: [External] Re: [RFC PATCH] sched: Enable root level cgroup
bandwidth control
On Wed, May 18, 2022 at 3:31 PM Vincent Guittot
<vincent.guittot@...aro.org> wrote:
> there is a DTPM powercap provider in the latest kernel and a scmi
> power capp provider is under review
Thanks, so DTPM can be a good solution for ARM. We could also deal
with AMD with acpi-cpufreq if powercap is not supported yet.
That aside, I think cpu cgroup has a familiar and simple sysfs
interface, and is more importantly hardware agnostic so it would be
really nice to have.
Alternatively, I assume we can look into a device-independent idle
injection mechanism?
Fam
Powered by blists - more mailing lists