linux-kernel - Re: SATA powersave patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Sep 2006 12:24:15 +0200
From:	Tejun Heo <htejun@...il.com>
To:	Pavel Machek <pavel@....cz>
CC:	kernel list <linux-kernel@...r.kernel.org>, axboe@...e.de
Subject: Re: SATA powersave patches

Hello, Pavel Machek.

Pavel Machek wrote:
> Thanks... I got it to work (on 2 the old tree, I was not able to
> forward-port it), but power savings were not too big (~0.1W, maybe).
> 
> I'm getting huge (~1W) savings by powering down SATA controller, as in
> ahci_pci_device_suspend().

Yeah, it only turns off SATA PHY, so it doesn't result in huge saving. 
IIRC, it was somewhere around 5 percent on my notebook w/ static 
linksave mode (turning PHY off on empty port).  But link powersaving 
introduces virtually no recognizable delay, so it's nice to have.

Can you check if there is any difference between [D/H]IPS and static? 
ICH6M on my notebook can't do DIPS/HIPS, so I couldn't compare them 
against static.

> It would be great to be able to power SATA
> controller down, then power it back up when it is needed... I tried
> following hack, but could not get it to work. Any ideas?

1. One way to do it would be by dynamic power management.  It would be 
nice to have wake-up mechanism at the block layer.  Idle timer can run 
in the block layer or it can be implemented in the userland.

ATM, this implies that the attached devices are powered down too 
(spindown).  As spinning up takes quite some time, we can implement 
another level of dynamic PM w/ shorter delay to wake up - drives are not 
spinned down but controllers are powered down completely.

In any case, channel reset and following revalidation are necessary on 
wake up - if the device is still spinning, this shouldn't take too long 
but it will introduce noticeable delay - probably under or around a sec.

2. Another hacky way would be implementing it as an extension of link 
powersaving.  I don't think this is a good idea tho.  Waking up a 
controller usually involves link reset which in turn requires 
revalidation and reconfiguration of attached device, which should be 
done from exception handler.

The reason why your hack doesn't work is probably this reason.  You need 
to pass the command to EH and tell it to perform full wake-up sequence 
and retry the command.

So, I think option #1 is the way to go - implementing leveled dynamic 
power management infrastructure and adding support in the block layer. 
What do you think?

Thanks.

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