> 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@xxxxxx> wrote: > From: Matthew Wilcox <matthew@xxxxxx> > Subject: Re: scsi_host_template.queuecommand() instances > To: "john smith" <whalajam@xxxxxxxxx> > Cc: linux-scsi@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
