From: Jeff Garzik <jeff@garzik.org>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: "Stephen M. Cameron" <scameron@beardog.cce.hp.com>,
James Bottomley <James.Bottomley@suse.de>,
"J.H." <warthog9@kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: hpsa: Convert SCSI LLD ->queuecommand() for host_lock less operation
Date: Sat, 29 Jan 2011 22:26:13 -0500 [thread overview]
Message-ID: <4D44DA55.7060505@garzik.org> (raw)
In-Reply-To: <1296340702.14831.219.camel@haakon2.linux-iscsi.org>
On 01/29/2011 05:38 PM, Nicholas A. Bellinger wrote:
> Hi Stephen and Co,
>
> Attached is a quick patch to enable modern SCSI host_lock' less
> operation for the HPSA SCSI LLD driver on>= .37 kernels. After an
> initial LLD conversion and review, I would like to verify with you that
> the following calls are currently protected by HPDA LLD internal locks
> that disable interrupts from the newly renamed hpsa_scsi_queue_command()
> dispatcher below..
>
> *) For cmd_alloc(), struct ctlr_info *h->lock + spin_lock_irqsave() is
> obtained and released.
>
> *) For enqueue_cmd_and_start_io(), struct ctlr_info *h->lock +
> spin_lock_irqsave() is obtained for addQ() + start_io() and released.
>
> So the one new piece wrt to host_lock less mode that is *not* protected
> in hpsa_scsi_queue_command() is the call to hpsa_scatter_gather(). This
> should be OK to get called without h->lock held w/ spin_lock_irqsave(),
> yes..?
>
> So far this patch has been compile tested only. Please have a look and
> comment.
>
> Thanks!
>
> --nab
>
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 12deffc..e205f33 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -1906,9 +1906,11 @@ sglist_finished:
> return 0;
> }
>
> -
> -static int hpsa_scsi_queue_command_lck(struct scsi_cmnd *cmd,
> - void (*done)(struct scsi_cmnd *))
> +/*
> + * Running in struct Scsi_Host->host_lock less mode using LLD internal
> + * struct ctlr_info *h->lock w/ spin_lock_irqsave() protection.
> + */
The way I read this comment, it initially misled me into thinking that
this queuecommand was somehow wrapped entirely within this protection
you described.
Only after an in-depth review did I figure out that cmd_alloc() and
enqueue_cmd_and_start_io() did all the locking necessary.
Therefore, here are some observations and recommendations:
* the code changes are correct. Reviewed-by: Jeff Garzik
<jgarzik@redhat.com>
* delete the comment. lack of "_lck" alone tells you its lockless.
* I question whether the following hpsa.c logic
lock_irqsave
cmd_alloc()
unlock_irqrestore
init cmd
lock_irqsave
enqueue
unlock_irqrestore
isn't more expensive than simply
lock_irqsave
cmd_alloc()
init cmd
enqueue
unlock_irqrestore
It seems like the common case would cycle the spinlock and interrupts
twice for an uncontended lock, which the initialization portion of the
cmd, which may indeed occur in parallel, is so cheap you'll spend more
time on the double-lock than anywhere else.
Jeff
next prev parent reply other threads:[~2011-01-30 3:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-29 22:38 hpsa: Convert SCSI LLD ->queuecommand() for host_lock less operation Nicholas A. Bellinger
2011-01-30 3:26 ` Jeff Garzik [this message]
2011-01-30 21:18 ` Nicholas A. Bellinger
2011-01-31 14:42 ` scameron
2011-01-31 20:26 ` Nicholas A. Bellinger
2011-02-01 9:13 ` Boaz Harrosh
2011-01-31 14:24 ` scameron
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=4D44DA55.7060505@garzik.org \
--to=jeff@garzik.org \
--cc=James.Bottomley@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=nab@linux-iscsi.org \
--cc=scameron@beardog.cce.hp.com \
--cc=warthog9@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.