From: Jens Axboe <axboe@suse.de>
To: Tejun Heo <htejun@gmail.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
alan@lxorguk.ukuu.org.uk, lkml@rtr.ca, forrest.zhao@intel.com,
linux-ide@vger.kernel.org
Subject: Re: [PATCH 09/12] libata: implement powersave timer
Date: Tue, 25 Jul 2006 10:01:32 +0200 [thread overview]
Message-ID: <20060725080131.GE4044@suse.de> (raw)
In-Reply-To: <44C47662.4010203@gmail.com>
On Mon, Jul 24 2006, Tejun Heo wrote:
> Jens Axboe wrote:
> >On Wed, Jul 19 2006, Jeff Garzik wrote:
> >>Tejun Heo wrote:
> >>>Implement powersave timer. It is primarily for OS-driven HIPS
> >>>implementation but can be used for any other PS purpose LLD sees fit.
> >>>During normal operation, PS timer is automatically started with
> >>>timeout ap->ps_timeout on port idle and stopped when the port becomes
> >>>busy. The timer is also stopped while EH.
> >>>
> >>>To minimize overhead and allow easy implementation of expected
> >>>operation model, ata_ps_timer_worker() is used as timer callback which
> >>>invokes LLD supplied ap->ps_timer_fn() if condition meets and also
> >>>helps implementing sequenced multi-step operation.
> >>>
> >>>Signed-off-by: Tejun Heo <htejun@gmail.com>
> >>This makes me wonder what Jens thinks about having a device idle timer
> >>and callback at the block level? At the very least, this feels like it
> >>should be implemented in the SCSI layer, or somewhere other than libata.
> >
> >Since this will be used only when the device is idle, we can reuse the
> >unplug timer and get it pretty much for free. So I think that's a good
> >idea.
> >
>
> Hello, Jeff, Jens.
>
> I agree that the unplug timer can be reused here but I'm not very sure
> about what the high level semantics would be. This timer tracks link
> idleness and also used to drive link power down sequence. e.g. For
> host-initiated partial/slumber powersave, the timer will be used like
> the following.
>
> 1. Timer for partial PS armed when the link becomes idle (100ms by
> default). The 'link' abstraction doesn't exist at the block layer yet,
> so this one is already problematic. I'm thinking of using link-wide
> idleness to implement powersave on ata_piix (ICH8 can access SCRs
> without enabling AHCI address space, hooray!) and possibly PMP. As
> ICH8s will end up on notebooks, supporting ata_piix is important.
>
> 2. On timer expiration, the PS handler is invoked and transits the link
> to partial power state. As the link also supports slumber mode, it
> re-arms the timer w/ 3s timeout.
>
> 3. On timer expiration, the PS handler wakes up the link because SATA
> link cannot transit directly from partial to slumber. As waking up
> takes time (1ms max by spec), the timer is rearmed (5ms).
>
> 4. On timer expiration, the link is put to slumber mode.
>
> In addition, whenever there is any event on the link, the timer is
> reset. Timer activation and canceling are tightly integrated into
> libata core layer to reduce overhead.
>
> This is very SATA specific and I don't think pushing this to upper layer
> is a good idea. Link powersave is closely related to transport topology
> and way too low level to be at block layer, IMHO.
As long as there's a 1:1 mapping between link and disk, the block layer
can easily be used. When that isn't the case, I think we should do the
cleaner thing and leave the link management to the layer that has such
knowledge.
--
Jens Axboe
next prev parent reply other threads:[~2006-07-25 8:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-17 6:52 [PATCHSET] libata: implement runtime link powersave Tejun Heo
2006-07-17 6:52 ` [PATCH 03/12] libata: add more SATA specific constants and macros to ata.h Tejun Heo
2006-07-19 19:32 ` Jeff Garzik
2006-07-17 6:52 ` [PATCH 04/12] libata: implement ata_all_ports list Tejun Heo
2006-07-19 19:34 ` Jeff Garzik
2006-07-17 6:52 ` [PATCH 02/12] libata: add ata_id_has_sata() and use it in ata_id_has_ncq() Tejun Heo
2006-07-17 6:52 ` [PATCH 01/12] libata: add msec_to_jiffies() Tejun Heo
2006-07-17 6:52 ` [PATCH 06/12] libata: add ata_port_nr_ready() Tejun Heo
2006-07-17 6:52 ` [PATCH 10/12] libata: implement standard powersave methods Tejun Heo
2006-07-19 19:50 ` Jeff Garzik
2006-07-17 6:52 ` [PATCH 08/12] libata: implement interface power management infrastructure Tejun Heo
2006-07-19 19:45 ` Jeff Garzik
2006-07-24 8:02 ` Tejun Heo
2006-07-17 6:52 ` [PATCH 11/12] ahci: implement link powersave Tejun Heo
2006-07-19 19:51 ` Jeff Garzik
2006-07-17 6:52 ` [PATCH 07/12] libata: implement sata_update_scontrol() Tejun Heo
2006-07-19 19:35 ` Jeff Garzik
2006-07-17 6:52 ` [PATCH 09/12] libata: implement powersave timer Tejun Heo
2006-07-19 19:48 ` Jeff Garzik
2006-07-19 20:22 ` Jens Axboe
2006-07-24 7:27 ` Tejun Heo
2006-07-25 8:01 ` Jens Axboe [this message]
2006-07-17 6:52 ` [PATCH 05/12] libata: make counting functions global Tejun Heo
2006-07-17 6:52 ` [PATCH 12/12] sata_sil24: implement link powersave Tejun Heo
2006-07-19 19:38 ` [PATCHSET] libata: implement runtime " Jeff Garzik
2006-07-24 7:33 ` Tejun Heo
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=20060725080131.GE4044@suse.de \
--to=axboe@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=forrest.zhao@intel.com \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=lkml@rtr.ca \
/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;
as well as URLs for NNTP newsgroup(s).