Re: [PATCH scsi-misc-2.6 03/05] scsi: make scsi_queue_insert() use blk_requeue_request()

[Jens Axboe]

On Wed, Apr 20 2005, James Bottomley wrote:
> On Wed, 2005-04-20 at 08:15 +0900, Tejun Heo wrote:
> > -	 * Insert this command at the head of the queue for it's device.
> > -	 * It will go before all other commands that are already in the queue.
> > -	 *
> > -	 * NOTE: there is magic here about the way the queue is plugged if
> > -	 * we have no outstanding commands.
> > -	 * 
> > -	 * Although this *doesn't* plug the queue, it does call the request
> > -	 * function.  The SCSI request function detects the blocked condition
> > -	 * and plugs the queue appropriately.
> 
> This comment still looks appropriate to me ... why do you want to remove
> it?
> 
> > +	 * Requeue the command.
> >  	 */
> > -	blk_insert_request(device->request_queue, cmd->request, 1, cmd, 1);
> > +	spin_lock_irqsave(q->queue_lock, flags);
> > +	blk_requeue_request(q, cmd->request);
> > +	spin_unlock_irqrestore(q->queue_lock, flags);
> > +
> > +	scsi_run_queue(q);
> 
> Really, wouldn't it be much more efficient simply to call blk_run_queue
> ()? since the blocked flags were set above, that's pretty much what
> scsi_run_queue() collapses to.

I wondered about this action recently myself. What is the point in
requeueing this request, only to call scsi_run_queue() ->
blk_run_queue() -> issue same request. If the point really is to reissue
the request immediately, I can think of many ways more efficient than
this :-)

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/