From: Len Brown <lenb@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
rjw@sisk.pl, balbir@linux.vnet.ibm.com,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
a.p.zijlstra@chello.nl, shaohua.li@intel.com,
svaidy@linux.vnet.ibm.com
Subject: Re: [git pull request] ACPI Processor Aggregator Driver for 2.6.32-rc1
Date: Mon, 05 Oct 2009 21:28:18 -0400 (EDT) [thread overview]
Message-ID: <alpine.LFD.2.00.0910052054540.309@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.01.0910051614510.3432@localhost.localdomain>
> ... we probably never want to even try
> to solve it in the scheduler, because why the hell should we care and add
> complex logic for something like that?
Today we take cores down to 100% idle, one at a time.
This is useful, but isn't the best we can do.
For we get zero "uncore" power savings.
As long as at least one core is active anywhere in the system,
all the uncores in all the packages in the system must remain active.
What a scheduler-based solution could do is
instead of taking, say, 1 of 64 cores down for 100%
of the period, it could take all 64 cores down
for 64th of the same period. This could get the hardware
into the deeper "package C-states", for a measurable
net power savings.
At the same time, this system-wide throttling may mitigate
some of the fairness/availability issues raised regarding
taking cores 100% off-line.
But doing this optimally will not be trivial.
The hardware must stay in the deep-sleep-states long enough
to make it worth the energy to enter and exit those states.
The hardware will flush the caches, having a performance
impact on all the cores. Device interrupts would prevent
the cores from sleeping, so they'd need to be somehow delayed
if we are to sleep long enough to make sleeping worth it etc.
cheers,
-Len Brown, Intel Open Source Technology Center
next prev parent reply other threads:[~2009-10-06 1:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-03 5:56 [git pull request] ACPI Processor Aggregator Driver for 2.6.32-rc1 Len Brown
2009-10-03 20:49 ` Rafael J. Wysocki
2009-10-05 3:32 ` Balbir Singh
2009-10-05 5:33 ` Vaidyanathan Srinivasan
2009-10-05 7:15 ` Balbir Singh
2009-10-05 19:59 ` Rafael J. Wysocki
2009-10-05 20:33 ` Balbir Singh
2009-10-05 20:56 ` Linus Torvalds
2009-10-05 21:51 ` Rafael J. Wysocki
2009-10-05 22:17 ` Len Brown
2009-10-05 21:04 ` Andrew Morton
2009-10-05 22:20 ` Len Brown
2009-10-05 22:40 ` Andrew Morton
2009-10-05 23:23 ` Linus Torvalds
2009-10-06 1:28 ` Len Brown [this message]
2009-10-06 9:16 ` Balbir Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.0910052054540.309@localhost.localdomain \
--to=lenb@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=shaohua.li@intel.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox