All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: "Brown, Len" <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	jesper.juhl@gmail.com, linux-kernel@vger.kernel.org, "Pallipadi,
	Venkatesh" <venkatesh.pallipadi@intel.com>
Subject: Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
Date: Tue, 26 Jul 2005 10:52:29 -0400	[thread overview]
Message-ID: <42E64E2D.7010700@tmr.com> (raw)
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B300424AE32@hdsmsx401.amr.corp.intel.com>

Brown, Len wrote:
>  
> 
>>>>Digging up this patch from last month regarding C2
>>>>on a AMD K7 implies
>>>>that the whole blame can be put on kernel acpi:
>>>>
>>>>http://marc.theaimsgroup.com/?l=linux-kernel&m=111933745131301&w=2
> 
> 
> The current Linus tree includes generic ACPI support
> for deep C-states on SMP machines. (deep means higher than C1)
> 
> I don't have any problem with people having platform specific
> modules to handle platform specific features.  However, if
> the system really intends to support SMP ACPI C-states deeper
> than C1 and the generic ACPI code doesn't support it,
> then it is either a Linux/ACPI bug or a BIOS bug -- file away:-)
> 
> I.e. The whole concept of ACPI is that you shoulud _not_ need
> a platform specific driver to accomplish this.

Is anyone but me interested in low power states for servers? I have 
several groups of servers which are lightly utilized for at least 12 
hours every day and on weekends. I currently use IDE drives so I can 
spin them down when idle, do logging either to a single drive or over 
the network whichever makes the most sense, and any drop in power use 
saves double, since I pay for the server power and the A/C power as well.

I haven't seen much discussion of this, but in many cases it would 
result in a saving, perhaps fairly large. Some environmental benefit as 
well, of course.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

  reply	other threads:[~2005-07-26 14:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-26  5:23 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference Brown, Len
2005-07-26 14:52 ` Bill Davidsen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-07-26  6:29 Voluspa
2005-07-21 18:04 Voluspa
2005-07-21 18:14 ` Jesper Juhl
2005-07-21 18:33   ` Voluspa
2005-07-22 14:48   ` Pavel Machek
2005-07-22 17:15     ` Voluspa
2005-07-22 18:02       ` Pavel Machek
2005-07-22 18:28         ` Voluspa
2005-07-22 18:44         ` Voluspa
2005-07-25 10:21           ` Tony Lindgren
2005-07-25 18:30             ` Bill Davidsen
2005-07-21 18:49 ` Guillaume Chazarain
2005-07-21 19:01   ` Voluspa
2005-07-26 13:14 ` Vojtech Pavlik
2005-07-26 14:53   ` Voluspa

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=42E64E2D.7010700@tmr.com \
    --to=davidsen@tmr.com \
    --cc=jesper.juhl@gmail.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=venkatesh.pallipadi@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.