From: Jeff Garzik <jgarzik@pobox.com>
To: Tejun Heo <htejun@gmail.com>
Cc: alan@lxorguk.ukuu.org.uk, lkml@rtr.ca, forrest.zhao@intel.com,
linux-ide@vger.kernel.org
Subject: Re: [PATCH 5/6] libata-pmp-prep: implement ops->qc_defer()
Date: Wed, 19 Jul 2006 16:32:10 -0400 [thread overview]
Message-ID: <44BE96CA.30008@pobox.com> (raw)
In-Reply-To: <11523378783771-git-send-email-htejun@gmail.com>
Tejun Heo wrote:
> Controllers which support PMP have various restrictions on which
> combinations of commands are allowed to what number of devices
> concurrently. This patch implements ops->qc_defer() which determines
> whether a qc can be issued at the moment or should be deferred.
>
> If the function returns ATA_DEFER_LINK, the qc will be deferred until
> a qc completes on the link. If ATA_DEFER_PORT, until a qc completes
> on any link. The defer conditions are advisory and in general
> ATA_DEFER_LINK can be considered as lower priority deferring than
> ATA_DEFER_PORT.
>
> ops->qc_defer() replaces fixed ata_scmd_need_defer(). For standard
> NCQ/non-NCQ exclusion, ata_std_qc_defer() is implemented. ahci and
> sata_sil24 are converted to use ata_std_qc_defer().
>
> ops->qc_defer() is heavier than the original mechanism because full qc
> is prepped before determining to defer it, but various information is
> needed to determine defer conditinos and fully translating a qc is the
> only way to supply such information in generic manner.
>
> IMHO, this shouldn't cause any noticeable performance issues as
>
> * for most cases deferring occurs rarely (except for NCQ-aware
> cmd-switching PMP)
> * translation itself isn't that expensive
> * once deferred the command won't be repeated until another command
> completes which usually is a very long time cpu-wise.
>
> Signed-off-by: Tejun Heo <htejun@gmail.com>
ACK patches 1-4.
For this patch (#5), I would much rather prefer to update ->qc_issue()
or ->qc_prep() to return a DEFER return value. That matches more
closely other APIs in Linux.
Jeff
next prev parent reply other threads:[~2006-07-19 20:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-08 5:51 [PATCHSET 2/3] prep for PMP support, take 2 Tejun Heo
2006-07-08 5:51 ` [PATCH 2/6] libata-pmp-prep: make a number of functions global to libata Tejun Heo
2006-07-08 5:51 ` [PATCH 1/6] libata-pmp-prep: add @new_class to ata_dev_revalidate() Tejun Heo
2006-07-08 5:51 ` [PATCH 3/6] libata-pmp-prep: separate out sata_link_hardreset() Tejun Heo
2006-07-08 5:51 ` [PATCH 6/6] libata-pmp-prep: implement qc_defer helpers Tejun Heo
2006-07-08 5:51 ` [PATCH 4/6] libata-pmp-prep: add @is_cmd to ata_tf_to_fis() Tejun Heo
2006-07-08 5:51 ` [PATCH 5/6] libata-pmp-prep: implement ops->qc_defer() Tejun Heo
2006-07-19 20:32 ` Jeff Garzik [this message]
2006-07-24 6:21 ` 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=44BE96CA.30008@pobox.com \
--to=jgarzik@pobox.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=forrest.zhao@intel.com \
--cc=htejun@gmail.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 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.