All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Lord <liml@rtr.ca>
To: kristen.c.accardi@intel.com
Cc: Jeff Garzik <jeff@garzik.org>,
	linux-ide@vger.kernel.org, arjan@linux.intel.com
Subject: Re: [patch 2/2] libata: power off unused ports
Date: Tue, 15 Apr 2008 15:02:40 -0400	[thread overview]
Message-ID: <4804FBD0.8060900@rtr.ca> (raw)
In-Reply-To: <20080414161122.03b2211d@appleyard>

Kristen Carlson Accardi wrote:
> On Sat, 12 Apr 2008 00:28:13 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
..
>> Thinking about the bigger pictures, powering off the phy is something we 
>> want to do in a lot more cases than this, but there is a stumbling 
>> block:  we wander into the realm of policy.
>>
>> For most users most of the time, empty SATA ports are needlessly 
>> powered.  The problem is that, at any given moment, a device may be 
>> hot-plugged, so we must be ready for that.  We need some way for the 
>> user to let the driver know that they will not be hotplugging anything 
>> anytime soon, permitting power savings to be enabled.
>>
>> A compromise solution that avoids adding a userspace "knob" has also 
>> been proposed (by Tejun, I think?):  power up the phy every N seconds, 
>> check for device, power down phy if nothing.  That should provide some 
>> power savings, though not as much as with a "knob" switched to "hotplug: 
>> off"
..

How long does a poll actually take, in real time?
Probably a hundred milliseconds or two, to see if the PHY syncs up?

So with a knob set to, say 2 seconds (sysfs), then this would
save 90% of the power of a permanent "off".  That's pretty good,
and setting that same knob to "infinity" (-1 ?) would achieve 100%.
Definitely a good way to go, IMHO.

> I think that for the common case - we should use HPCP to determine if
> the suggested use of the port is for hot plug.  I can see your point
> about wanting to give the user the option to just disregard the intended
> use of the port and do what they want, but I say we don't make that
> the default behavior.  And, I don't like the idea of adding another
> wakeup in the driver to do polling - seems like 99% of users are
> going to be just fine with a knob - and that they should only
> have to use the knob to override the default (or how bout a 
> module param?).  I don't think we should compromise power for a 
> feature that most people are unlikely to use (if HPCP is not set).
..

I worry that this is far too x86 / vendor specific.
Most of the SATA ports I have here, for example, probably lack this HPCP bit
even on x86, and on other arch's it likely doesn't exist at all, right?

For arch/system/device that does have HPCP implemented, then sure,
it could be used to automatically tweak the sysfs knob.
But from userspace perhaps, rather than kernel ?

Thanks


  reply	other threads:[~2008-04-15 19:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080325221646.567639335@intel.com>
2008-03-25 22:28 ` [patch 1/2] ahci: Dont start port DMA engines unless a device is present Kristen Carlson Accardi
2008-04-12  4:21   ` Jeff Garzik
2008-03-25 22:28 ` [patch 2/2] libata: power off unused ports Kristen Carlson Accardi
2008-03-28  7:43   ` Andi Kleen
2008-03-28 17:00     ` Kristen Carlson Accardi
2008-04-12  4:28   ` Jeff Garzik
2008-04-14 23:11     ` Kristen Carlson Accardi
2008-04-15 19:02       ` Mark Lord [this message]
2008-04-24 17:45         ` Kristen Carlson Accardi

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=4804FBD0.8060900@rtr.ca \
    --to=liml@rtr.ca \
    --cc=arjan@linux.intel.com \
    --cc=jeff@garzik.org \
    --cc=kristen.c.accardi@intel.com \
    --cc=linux-ide@vger.kernel.org \
    /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.