Re: scsi_host_template.queuecommand() instances

[john smith <whalajam@yahoo.com>]

> Not correct, they could easily be for the same LUN.

Of course, if there are concurrent application threads accessing the same (Target,LUN).

> Linux doesn't use threads like this ... what usually
> happens is a
> user thread makes a syscall (eg write() or read()) or
> faults on an
> mmaped region.  The thread switches into kernel mode,
> and winds its way
> through the file system, into the page cache, then the
> block layer, down
> to the scsi layer, and invokes queuecommand.  Once
> queuecommand finishes,
> the thread returns to the page cache to wait for the I/O to
> complete.

How does the queuecommand get called for concurrent application threads  before 2.6.37?

thanks,
John 


--- On Sun, 2/27/11, Matthew Wilcox <matthew@wil.cx> wrote:

> From: Matthew Wilcox <matthew@wil.cx>
> Subject: Re: scsi_host_template.queuecommand() instances
> To: "john smith" <whalajam@yahoo.com>
> Cc: linux-scsi@vger.kernel.org
> Date: Sunday, February 27, 2011, 2:21 PM
> On Sun, Feb 27, 2011 at 11:22:06AM
> -0800, john smith wrote:
> > I understand that inside LDD's
> scsi_host_template.queuecommand(), the card->spinlock can
> be used to protect shared data between concurrent instances
> of queuecommand and bottom-half/tasklets IO completion
> code.
> > For SMP system with PCIE/MSIX enabled interrupts,
> there can be multiple instances of completion tasklets.
> > The questions I have are:
> >  
> > - can there be multiple instances of queuecommand as
> well?
> 
> Yes, queuecommand can be called on multiple CPUs
> simultaneously.
> That's only been true since 2.6.37, though.
> 
> > - if so, I would assume they are IO commands issued
> for different targets (controlled by LDD), correct?
> 
> Not correct, they could easily be for the same LUN.
> 
> > Also, if true, these multiple instances must be
> running on different kernel threads spwaned by the SCSI mid
> layer, or block layer?
> 
> Linux doesn't use threads like this ... what usually
> happens is a
> user thread makes a syscall (eg write() or read()) or
> faults on an
> mmaped region.  The thread switches into kernel mode,
> and winds its way
> through the file system, into the page cache, then the
> block layer, down
> to the scsi layer, and invokes queuecommand.  Once
> queuecommand finishes,
> the thread returns to the page cache to wait for the I/O to
> complete.
> 
> > Links to detailed and uptodate Block layer description
> would be appreciated (the ones I found are either old and
> superficial),
> 
> It's a lot of effort to keep these things up to date, and
> generally those
> making the changes don't have the interest in updating
> documentation.
> 
> -- 
> Matthew Wilcox       
>         Intel Open Source
> Technology Centre
> "Bill, look, we understand that you're interested in
> selling us this
> operating system, but compare it to ours.  We can't
> possibly take such
> a retrograde step."
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


      
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html