All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>, Tejun Heo <htejun@gmail.com>
Subject: Re: [PATCH] libata: rewrite SCSI host scheme to be one per ATA host
Date: Thu, 23 Apr 2009 06:39:39 -0400	[thread overview]
Message-ID: <49F0456B.2050502@garzik.org> (raw)
In-Reply-To: <20090423063542.GK4593@kernel.dk>

Jens Axboe wrote:
> On Wed, Apr 22 2009, Jeff Garzik wrote:
>> Jeff Garzik wrote:
>>> Currently, libata creates a Scsi_Host per port.  This was originally
>>> done to leverage SCSI's infrastructure to arbitrate among master/slave
>>> devices, but is not needed for most modern SATA controllers.   And I
>>> _think_ it is not needed for master/slave if done properly, either.
>> BTW note the above, with regards to the libata SCSI->block conversion.  
>> libata currently relies on SCSI for some amount of generic device  
>> arbitration, in several situations (see ->qc_defer,  
>> SCSI_MLQUEUE_.*_BUSY).  libata expects SCSI to be intelligent and not  
>> starve devices, etc.
> 
> Defer looks like internal policy, I don't see that functioning any
> different in the block layer. SCSI_MLQUEUE_*_BUSY in SCSI is primarily
> using the block layer functionality of BLKPREP_DEFER to begin with, so I
> think we're pretty close to providing all that already.

It's not quite that simple.  I am referring mainly to arbitration across 
multiple request_queue's.  SCSI has useful code in place to deal with 
target-busy and host-busy conditions, both of which could potentially be 
blocking and unblocking multiple request queues.

mlqueue is much more than just a wrapper over block requeueing 
functions.  Read scsi_next_command() and scsi_run_queue(), and grep for 
starved_list, host_{busy,blocked}, target_{busy,blocked}, 
device_{busy,blocked}.

In our master/slave case, we must choose between queue A and queue B, 
making sure to starve neither.  For simplex DMA, we potentially have 
queues A, B, C and D serving requests across the "bus bottleneck," and 
must ensure no starvation of A, B, C or D.


Although I have no code to back this up, my gut feeling is that a 
"request queue group" object, with associated functions, that would be 
the appropriate place for cross-queue or "host-wide" (as in, struct 
Scsi_Host or struct ata_host) functionality.

Whatever the solution, libata definitely makes use of SCSI's 
cross-request_queue arbitration, so any move to block will require 
similar functionality.

	Jeff




  reply	other threads:[~2009-04-23 10:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-22  9:09 [PATCH] libata: rewrite SCSI host scheme to be one per ATA host Jeff Garzik
2009-04-22  9:23 ` Jeff Garzik
2009-04-22 12:16   ` Boaz Harrosh
2009-04-22 15:10     ` Daniela Engert
2009-04-22 15:18       ` Alan Cox
2009-04-22 15:37         ` James Bottomley
2009-04-22 16:27           ` Alan Cox
2009-04-22 18:36           ` Jeff Garzik
2009-04-22 19:27             ` James Bottomley
2009-04-22 16:48     ` Jeff Garzik
2009-04-23  6:35   ` Jens Axboe
2009-04-23 10:39     ` Jeff Garzik [this message]
2009-04-23 10:43       ` Jens Axboe
2009-04-22 13:09 ` Mark Lord
2009-04-22 16:52   ` Jeff Garzik
2009-04-22 19:08 ` Grant Grundler
2009-04-23 11:00   ` Jeff Garzik
2009-04-23 17:59     ` Grant Grundler
2009-04-23 18:09       ` James Bottomley
2009-04-24 11:00   ` Stefan Richter

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=49F0456B.2050502@garzik.org \
    --to=jeff@garzik.org \
    --cc=htejun@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.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.