From: Erik Slagter <erik@slagter.name>
To: Len Brown <lenb@kernel.org>, ykzhao <yakui.zhao@intel.com>
Cc: linux-acpi@vger.kernel.org
Subject: Re: No c2-c7 states on core i7
Date: Mon, 23 Nov 2009 20:26:53 +0100 [thread overview]
Message-ID: <4B0AE1FD.4030108@slagter.name> (raw)
In-Reply-To: <alpine.LFD.2.00.0911231101150.858@localhost.localdomain>
> No, that isn't normal. C-states on modern processors generally
> save a lot of energy.
>
> If you run powertop and you find that you are over 99% idle
> and you save no energy compared to when you are 0% idle
> (say a copy of "cat /dev/zero> /dev/null" for each core)
> then something is wrong with your system.
I just removed a large story here, I guess the table from my other
message is a lot more informative.
> It is possible, but as soon as you reverse engineer and over-ride
> something in the BIOS, you are on very thin ice. Presumably
> the BIOS engineer made a concious decision to disable C-states
> when you over-clock your board and had a reason to do so.
As long as nothing gets fried that's no problem for me.
> Maybe the more important question is what measurable benefit
> you get when you over-clock your board, and if you really need that...
I can understand your doubts on this matter, but I think I do have a
legitimate reasoning. This is a server that almost all of the time does
next to nothing. Load 0.02 or similar. It needs to be running 24/24
though because it receives e-mail and answers the telephone. So that's
why I want it to be low on power usage. On the other hand I need to
transcode movie clips to h264 very regularly. I can use every 4*2 core
for the process using x264 and indeed it works very fast. Also I noticed
that every mhz higher clock means shorter encoding time, all
(virtual-)cores get completely loaded. The "normal" speed of the 920 is
2.8 Ghz (or in fact 2.63 Ghz) and a change to 3.4 Ghz really does make a
difference in encoding speed, theoretically 30%, in practise even more.
Intel would really make me happy if they would design a processor with
four or more cores and a chipset that would implement C7 and also could
scale from 100 Mhz to 3.6 Ghz, in two or three steps, I wouldn't mind,
and then would use something like 20 watts in idle, like my laptop does.
next prev parent reply other threads:[~2009-11-23 19:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-20 14:28 No c2-c7 states on core i7 Erik Slagter
2009-11-21 17:45 ` Erik Slagter
2009-11-22 11:46 ` c1/c1e/c3/c6/c7 on linux Erik Slagter
2009-11-23 3:05 ` No c2-c7 states on core i7 ykzhao
2009-11-23 8:52 ` Erik Slagter
2009-11-23 16:11 ` Len Brown
2009-11-23 19:23 ` Erik Slagter
2009-11-23 19:26 ` Erik Slagter [this message]
2009-11-24 13:34 ` Jindrich Makovicka
2009-11-24 13:55 ` Erik Slagter
2009-11-25 6:59 ` Len Brown
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=4B0AE1FD.4030108@slagter.name \
--to=erik@slagter.name \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=yakui.zhao@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