linux-kernel - Re: RFC: A proposal for power capping through forced idle in the Linux Kernel

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: <20091217030144.186b1b19@infradead.org>
Date:	Thu, 17 Dec 2009 03:01:44 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Salman Qazi <sqazi@...gle.com>
Cc:	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michael Rubin <mrubin@...gle.com>,
	Taliver Heath <taliver@...gle.com>
Subject: Re: RFC: A proposal for power capping through forced idle in the 
 Linux Kernel

On Tue, 15 Dec 2009 12:15:30 -0800
Salman Qazi <sqazi@...gle.com> wrote:

> > (having the memory power in a machine suddenly be half or less is a
> > huge step in power, for something, the alignment itself, that does
> > not cost much if any extra performance over randomly distributed
> > idle insertions)
> 
> I think there is a difference in goals here.  Our goal is to free up
> power from one machine, so that it can be used elsewhere.  This means
> that any power that we save has to be predictably saved. 

unless your population of machines is big enough, and you get "close
enough" in terms of predictability.

> We have
> models that map between CPU time and power usage, that have to account
> for the worst case.

the delta between worst case and average/typical even for cpu time <->
power usage is enormous (2x to 3x would not surprise me)... adding
memory to that equation does not change the fundamentals much.



> Having said that, energy savings is a worthy goal by itself.  But, we
> have to make sure to balance it with performance.

I would think the people who pay the power bill at the end of the month
would notice a 10% reduction ;-)


> > as long as the tentative portion of the idle time gets injected at
> > the same time.. I suspect there can be a decent balance here where
> > most of the time we get the full CPU *and* memory savings, while we
> > degrade gracefully for the case where we get increasingly more
> > interactive activity.
> 
> Let me rephrase what you just said to verify that I understand you
> correctly:  we should align the enforcement intervals across CPUs and
> thereby eagerly inject over the same time period across multiple CPUs.

we should at least try hard to do this. it's ok to not always get it, 
but when we can we should.

>  If there is no interactive workload then we would get maximal CPU and
> memory savings.  If there are interactive tasks, then we just let them
> run like we would in the eager injection in original design.

the interactive tasks would indeed run "normal"; but since they are
interactive that is supposedly "only sporadic".
--
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/