[patch 0/2] SATA Link Power Management patches

[Kristen Carlson Accardi]

Here's a set of patches which implement link power management for SATA. 
We had talked at kernel summit of moving sysfs interface for setting
the link power management policy to the block layer, but after a 
lot of consideration, I think this doesn't make sense.  Mainly because
I feel for SATA the link power management policy should be associated
with the controller, not with the device. So, we continue to use
the shost_attrs array in the scsi host template to create a sysfs
interface that is associated with the scsi_host class. 

These patches have changed since the last version.  The patches have
been refreshed to use the new ata_link structures.  Additionally, I've
separated out DIPM enabling and put it into libata-core, because DIPM
can be used by any SATA disk that is attached to a controller which
allows DIPM, although in this implementation the driver will need
to explicitly set a flag which would indicate to the core that it
is OK to set DIPM.  This is because all interface power state changes
can cause Phy Ready interrupts, and the driver will need to know
to ignore them. DIPM will only be enabled for the min_power link
power management policy value.  This is because many disks are not
clever enough to know that if a controller naks their request for
a SLUMBER transition, they should retry for PARTIAL - instead they
will just give up all together.

With these patches, measured on my X60 with a Watts Up Pro meter,
in the base station after all powertop suggestions have been applied,  
I see a savings of approximately .7-.8 W in min_power mode, and
.5 W in medium_power mode.  For the best power/performance tradeoff,
it's recommended that you use the "medium_power" setting, although
min_power can be used of course when you absolutely need to save
every 10th of a watt and don't care about the additional performance
loss.

Please give them a try.
Thanks,
Kristen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/