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: <20140120204452.GB26780@amd.pavel.ucw.cz>
Date:	Mon, 20 Jan 2014 21:44:52 +0100
From:	Pavel Machek <pavel@....cz>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Morten Rasmussen <Morten.Rasmussen@....com>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"mingo@...nel.org" <mingo@...nel.org>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"markgross@...gnar.org" <markgross@...gnar.org>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [11/11] system 1: Saving energy using DVFS

Hi!

> > > Race to idle doesn't mean that the screen goes off as well. Let's say
> > > the screen stays on for 1 min and the CPU needs to be running for 10s
> > > over this minute, in the first case you have:
> > 
> > No, it does not. I just assumed user is continuing to use his
> > machine. Obviously, waiting 60 seconds with screen on will make the
> > difference look smaller. But your solution still means user has to
> > wait longer _and_ you consume more battery doing so.
> > 
> > And this is for any task where user waits for result with screen
> > on. Like rendering a webpage. Like opening settings screen. Like
> > installing application.
> 
> Page rendering should make very little difference to power since the
> reading (screen on) time is much larger than the rendering (CPU)
> time.

For some uses, yes, for some uses (searching for bus time tables,
displaying weather) not neccessarily. And I suspect that the whole CPU
consumption takes a little difference in power, anyways...

> But what I'm pointing at for 10s/60s ratios are thing like games or
> video playing where the CPU is running for 1/6 of the time and idle for
> the other 5/6. We get better energy figures by changing the run time to
> 3/6 and idle at 3/6.

Better energy figures on complete system consumption, on phone-type
device that can be bought in the shop?

> > But hey, maybe you are right and running at lowest possible frequency
> > is right. Please provide concrete numbers like I did.
> 
> They've been anonymised (for many reasons) and you have the right not to
> trust them. But do you really think we are making up the numbers? We

"Here is power consumption of unspecified part of machine in
unspecified units on machine of unspecified type. Trust us our patches
improve it in unspecified workload". Why should I trust you?

> have a great interest in the Linux scheduler working efficiently on the
> ARM platforms rather than optimising it for non-existent scenarios. If
> at some point this argument becomes a blocking factor, I'm sure we can
> share the real numbers with the relevant parties under an NDA.

I'm sure you can just buy Samsung S4 in the nearest shop, and you
probably can find and ampermeter on site... Then perhaps people can
reproduce your results and we can have useful discussion. This is
relevant to production hardware, right?

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ