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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.