public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
To: Andi Kleen <ak@linux.intel.com>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
	Eric Moore <Eric.Moore@lsi.com>,
	linux-scsi@vger.kernel.org, vasu.dev@intel.com,
	willy@linux.intel.com, Mike Christie <michaelc@cs.wisc.edu>,
	Hannes Reinecke <hare@suse.de>,
	James Smart <James.Smart@Emulex.Com>,
	Andrew Vasquez <andrew.vasquez@qlogic.com>
Subject: Re: [PATCH] scsi, mptsas : drop scsi_host lock when calling mptsas_qcmd
Date: Thu, 16 Sep 2010 14:48:08 -0700	[thread overview]
Message-ID: <1284673688.13344.105.camel@haakon2.linux-iscsi.org> (raw)
In-Reply-To: <1284673478.13344.101.camel@haakon2.linux-iscsi.org>

On Thu, 2010-09-16 at 14:44 -0700, Nicholas A. Bellinger wrote:
> On Thu, 2010-09-16 at 14:34 -0700, Nicholas A. Bellinger wrote:
> > On Thu, 2010-09-16 at 23:25 +0200, Andi Kleen wrote:
> > > > I asked James about getting Vasu's unlocked_qcmds=1 patch merged, but he
> > > > convinced me that doing conditional locking while is very simple, is not
> > > > the proper way for getting this resolved in mainline code.  I think in
> > > > the end this will require a longer sit down to do a wholesale conversion
> > > > of all existing SCSI LLD drivers, and identifing the broken ones that
> > > > still need a struct Scsi_Host->host_lock'ed SHT->queuecommand() for
> > > > whatever strange & legacy reasons.
> > > 
> > > The standard way to do that would be to first move the lock down
> > > into the drivers (similar to how it has been done with the BKL).
> > > This would be a fairly mechanic mindless patch. Lots of typing,
> > > but not really a lot of real code review needed.
> > > 
> > > Then next step the drivers who know they don't want it can remove it.
> > 
> > Well, the main bit is finding those drives that actually call some form
> > of struct Scsi_Host->host_lock unlock() -> do_work() -> lock() from
> > within their own ->queuecomamnd() caller, and avoid running into the big
> > ugly deadlock that would happen here..
> > 
> > I know that Open-iSCSi and my own iSCSI Initiator do this
> > "optimization", but I am not sure which other LLDs also do this as
> > well..
> > 
> > Best,
> > 
> 
> Ok, spotted another one of these in drivers/scsi/lpfc/lpfc_scsi.c:lpfc_queuecommand():
> 
> 	<SNIP>
> 
>         if (phba->cfg_poll & ENABLE_FCP_RING_POLLING) {
>                 spin_unlock(shost->host_lock);
>                 lpfc_sli_handle_fast_ring_event(phba,
>                         &phba->sli.ring[LPFC_FCP_RING], HA_R0RE_REQ);
> 
>                 spin_lock(shost->host_lock);
>                 if (phba->cfg_poll & DISABLE_FCP_RING_INT)
>                         lpfc_poll_rearm_timer(phba);
>         }
> 
>         return 0;
> 
> Best,

And ditto ->queuecommand() with qla2xxx and qla4xxx LLDs as well:

	<SNIP>

        spin_unlock_irq(ha->host->host_lock);

        srb = qla4xxx_get_new_srb(ha, ddb_entry, cmd, done);
        if (!srb)
                goto qc_host_busy_lock;

        rval = qla4xxx_send_command_to_isp(ha, srb);
        if (rval != QLA_SUCCESS)
                goto qc_host_busy_free_sp;

        spin_lock_irq(ha->host->host_lock);
        return 0;


So yeah, it looks like the high performance LLDs have adopted this trick
over the years..  :-)

Best,

--nab



  reply	other threads:[~2010-09-16 21:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-16 19:44 [PATCH] scsi, mptsas : drop scsi_host lock when calling mptsas_qcmd Tim Chen
2010-09-16 20:48 ` Nicholas A. Bellinger
2010-09-16 21:18   ` Tim Chen
2010-09-16 21:25   ` Andi Kleen
2010-09-16 21:24     ` James Bottomley
2010-09-16 23:25       ` Christoph Hellwig
2010-09-17  0:13         ` Nicholas A. Bellinger
2010-09-17  1:12           ` Vasu Dev
2010-09-16 21:34     ` Nicholas A. Bellinger
2010-09-16 21:44       ` Nicholas A. Bellinger
2010-09-16 21:48         ` Nicholas A. Bellinger [this message]
2010-09-16 22:00     ` Joe Eykholt
2010-09-16 22:16       ` James Bottomley
2010-09-17  7:16         ` Andi Kleen
2010-09-17 10:32           ` Bart Van Assche
2010-09-17 12:19             ` James Bottomley
2010-09-16 22:26       ` Tim Chen
2010-09-16 21:31   ` Vasu Dev

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=1284673688.13344.105.camel@haakon2.linux-iscsi.org \
    --to=nab@linux-iscsi.org \
    --cc=Eric.Moore@lsi.com \
    --cc=James.Smart@Emulex.Com \
    --cc=ak@linux.intel.com \
    --cc=andrew.vasquez@qlogic.com \
    --cc=hare@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    --cc=tim.c.chen@linux.intel.com \
    --cc=vasu.dev@intel.com \
    --cc=willy@linux.intel.com \
    /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