public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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