linux-kernel - Re: [RFC PATCH v4 00/14] sched: packing small tasks

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAKfTPtA052Lv6oyOqc-t1meVt9wfG1RtVaxMT5PeYPYG_XmdVA@mail.gmail.com>
Date:	Thu, 2 May 2013 11:12:32 +0200
From:	Vincent Guittot <vincent.guittot@...aro.org>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	LAK <linux-arm-kernel@...ts.infradead.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Paul Turner <pjt@...gle.com>,
	Santosh <santosh.shilimkar@...com>,
	Morten Rasmussen <Morten.Rasmussen@....com>,
	Chander Kashyap <chander.kashyap@...aro.org>,
	"cmetcalf@...era.com" <cmetcalf@...era.com>,
	"tony.luck@...el.com" <tony.luck@...el.com>,
	Alex Shi <alex.shi@...el.com>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Len Brown <len.brown@...el.com>,
	Amit Kucheria <amit.kucheria@...aro.org>,
	Jonathan Corbet <corbet@....net>,
	Lukasz Majewski <l.majewski@...sung.com>
Subject: Re: [RFC PATCH v4 00/14] sched: packing small tasks

On 26 April 2013 17:46, Arjan van de Ven <arjan@...ux.intel.com> wrote:
>>>
>>>
>>> so I got to ask the hard question; what percentage of system level (not
>>> just
>>> cpu level)
>>> power consumption gain can you measure (pick your favorite workload)...
>>>
>>
>> I haven't system level figures for my patches but only for the cpu
>> subsystem. If we use the MP3 results in the back of my mail, they show
>> an improvement of 37 % (113/178) for the CPU subsystem of the
>> platform. If we assume that the CPU subsystem contributes 25% of an
>> embedded system power consumption (this can vary across platform
>> depending of the use of HW accelerator but it should be a almost fair
>> percentage), the patch can impact the power consumption on up to 9%.
>>
>
> sadly the math tends to not work quite that easy;
> memory takes significantly more power when the system is not idle than when
> it is idle for example. [*]
> so while reducing cpu power by making it run a bit longer (at lower
> frequency or
> slower core or whatever) is a pure win if you only look at the cpu, but it
> may
> (or may not) be a loss when looking at a whole system level.
>
> I've learned the hard way that you cannot just look at the cpu numbers; you
> must look
> at the whole-system power when playing with such tradeoffs.
>
> That does not mean that your patch is not useful; it very well can be, but
> without having looked at whole-system power that's a very dangerous
> conclusion to make.
> So.. if you get a chance, I'd love to see data on a whole-system level...
> even for just one workload
> and one system
> (playing mp3 sounds like a quite reasonable workload for such things indeed)

Hi Arjan,

I don't have full system power consumption but i have gathered some
additional figures for mp3 use case

The power consumption percentage stay similar
             | CA15  | CA7   | total  |
-------------------------------------
default       |  81%  |   95% | 178%   |
pack          |  10%  |  100% | 110%   |
agressive     |  3%   |  100% | 103%   |
-------------------------------------

I have also gathered the time when all CPUs are in low power state so
the entire system can be put in low power mode (DDR in self refresh)
                 |  Time | nb / sec | average |
--------------------------------------------
default       | 85.5% | 296      | 2.9ms   |
pack          | 82.5% | 253      | 3.2ms   |
agressive     | 81.8% | 236      | 3.4ms   |
--------------------------------------------

We can see a decrease of the time spent in low power mode but on the
other side, the number of switch to low power mode also decreases
which results in the increase the average duration of low power state.

Regards,
Vincent

>
>
> [*] I assume that on your ARM systems, memory goes into self refresh during
> system idle just as it does on x86
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/