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]
Date:   Wed, 13 Jun 2018 23:27:28 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     "Pandruvada, Srinivas" <srinivas.pandruvada@...el.com>,
        "viresh.kumar@...aro.org" <viresh.kumar@...aro.org>,
        "rjw@...ysocki.net" <rjw@...ysocki.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "Zhang, Rui" <rui.zhang@...el.com>,
        "edubezval@...il.com" <edubezval@...il.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "andrea.parri@...rulasolutions.com" 
        <andrea.parri@...rulasolutions.com>,
        "kevin.wangtao@...aro.org" <kevin.wangtao@...aro.org>,
        "leo.yan@...aro.org" <leo.yan@...aro.org>,
        "daniel.thompson@...aro.org" <daniel.thompson@...aro.org>,
        "javi.merino@...nel.org" <javi.merino@...nel.org>,
        "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>
Subject: Re: [PATCH V6] powercap/drivers/idle_injection: Add an idle injection framework

On Wed, Jun 13, 2018 at 10:35 PM, Daniel Lezcano
<daniel.lezcano@...aro.org> wrote:
> On 13/06/2018 22:32, Pandruvada, Srinivas wrote:
>> On Wed, 2018-06-13 at 22:19 +0200, Daniel Lezcano wrote:
>>> On 13/06/2018 22:07, Pandruvada, Srinivas wrote:
>>>> On Wed, 2018-06-13 at 22:00 +0200, Daniel Lezcano wrote:
>>>>> On 13/06/2018 17:54, Pandruvada, Srinivas wrote:
>>>>>> On Tue, 2018-06-12 at 14:00 +0200, Daniel Lezcano wrote:
>>>>>>> Initially, the cpu_cooling device for ARM was changed by
>>>>>>> adding a
>>>>>>> new
>>>>>>> policy inserting idle cycles. The intel_powerclamp driver
>>>>>>> does a
>>>>>>> similar action.
>>>>>>>
>>>>>>> Instead of implementing idle injections privately in the
>>>>>>> cpu_cooling
>>>>>>> device, move the idle injection code in a dedicated framework
>>>>>>> and
>>>>>>> give
>>>>>>> the opportunity to other frameworks to make use of it.
>>>>>>>
>>>>>>> The framework relies on the smpboot kthreads which handles
>>>>>>> via
>>>>>>> its
>>>>>>> main loop the common code for hotplugging and [un]parking.
>>>>>>>
>>>>>>> This code was previously tested with the cpu cooling device
>>>>>>> and
>>>>>>> went
>>>>>>> through several iterations. It results now in split code and
>>>>>>> API
>>>>>>> exported in the header file. It was tested with the cpu
>>>>>>> cooling
>>>>>>> device
>>>>>>> with success.
>>>>>>>
>>>>>>
>>>>>> May be I have missed, but I don't see any use of powercap
>>>>>> sysfs.
>>>>>>
>>>>>> We created powercap sys that user space is presented a common
>>>>>> interface
>>>>>> for power capping. The RAPL driver was also submitted as
>>>>>> cooling
>>>>>> device
>>>>>> before, but suggestion was to create this powercap.
>>>>>>
>>>>>> So if powercap interface is not enough then may be we should
>>>>>> enhance
>>>>>> that.
>>>>>
>>>>> We are creating a framework for idle injection. This framework
>>>>> can
>>>>> then
>>>>> be used by the cpu_cooling device, the power_clamp and in
>>>>> addition a
>>>>> power capping for ARM (if it makes sense).
>>>>
>>>> But in this case, why in drivers/powercap folder as this is another
>>>> framework?
>>>
>>> I presented at OSPM 2nd the cpu idle cooling device. It is ARM
>>> specific
>>> but has some similarities with the power clamp driver.
>>>
>>> Some board come with power numbers defined in their DT and from there
>>> we
>>> are able to compute a targeted power by injecting idle cycles.
>>>
>>> As the idle injection allows to do also power capping, Rafael told me
>>> to
>>> move that to a framework (may be better say a component with exported
>>> services or library) and put it in drivers/powercap.
>> So Rafael wants it to be in powercap.
>
> That is what I understood.

While this is not exactly power capping, the purpose of this mechanism
is to prevent too much power from being drawn by the system, so IMO it
falls under the same broad category.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ