From: Andi Kleen <andi@firstfloor.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Andi Kleen <andi@firstfloor.org>, Mike Galbraith <efault@gmx.de>,
Frederik Deweerdt <deweerdt@free.fr>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
suresh.b.siddha@intel.com, Ingo Molnar <mingo@elte.hu>
Subject: Re: BUG: unable to handle kernel NULL pointer dereference at 00000002
Date: Tue, 29 Jul 2008 18:31:13 +0200 [thread overview]
Message-ID: <20080729163113.GP30344@one.firstfloor.org> (raw)
In-Reply-To: <20080729083029.094a32cb@infradead.org>
> > A power saving feature that has a significant trade off between power
> > and performance.
>
> do you have numbers to explain "significant tradeoff" ?
I don't have numbers, but from the theory it seems pretty clear.
When you e.g. have two processes with 6MB cache foot print and
you have two 2C CPUs with 6MB cache they will fit in cache, but
with power aware scheduler they won't because both processes will run on
the single 6MB package. With NUMA the effect is even worse because
also the memory controllers are not used evenly.
And there's the FSB bandwidth, but that's a secondary issue.
>
>
> > This means performance will go down. Perhaps it would be ok on
> > battery,
>
> the illusion that power only matters on battery got buried a few years
> ago ;)
My understanding was always that unless you're on battery power saving
features that are enabled by default are not supposed to impact performance
significantly. When the user says impacting performance is ok then
doing that is fine of course, but not by default. And I don't think
that's an illusion. In fact if power saving means losing a lot of performance
people would get discouraged from using it, and surely you don't want that.
-Andi
next prev parent reply other threads:[~2008-07-29 16:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-25 9:53 BUG: unable to handle kernel NULL pointer dereference at 00000002 Aneesh Kumar K.V
2008-07-28 22:26 ` Frederik Deweerdt
2008-07-29 4:22 ` Mike Galbraith
2008-07-29 12:09 ` Andi Kleen
2008-07-29 13:56 ` Arjan van de Ven
2008-07-29 14:53 ` Andi Kleen
2008-07-29 15:30 ` Arjan van de Ven
2008-07-29 16:31 ` Andi Kleen [this message]
2008-07-29 17:22 ` Arjan van de Ven
2008-07-29 17:50 ` Andi Kleen
2008-07-30 9:05 ` Ingo Molnar
2008-07-30 9:26 ` Andrew Morton
2008-07-30 16:31 ` Greg KH
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=20080729163113.GP30344@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=arjan@infradead.org \
--cc=deweerdt@free.fr \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.com \
/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