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] [day] [month] [year] [list]
Message-ID: <CAKfTPtB9gd5M6vvX+h3aZdOBVkWw0d+U5G5kUUtwsWuH_vanZA@mail.gmail.com>
Date:   Mon, 23 May 2022 17:36:29 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     "Feiran Zheng ." <fam.zheng@...edance.com>
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, 18 May 2022 at 17:55, Feiran Zheng . <fam.zheng@...edance.com> wrote:
>
> 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.

cgroup is about allocating runtime to a group but you want to force a
system idle for power consideration so it looks like abusing the
interface

>
> Alternatively, I assume we can look into a device-independent idle
> injection mechanism?

Yes, idle injection is  device-independent and fit better with your needs

thermal framework already support cpu idle cooling device but I'm not
sure your case is only related to thermal so you might want a more
generic interface like powercap--> dtpm --> idle injection

>
> Fam

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ