Re: [PATCH] fixes and cleanups for the new command allocation code

[James Bottomley <James.Bottomley@steeleye.com>]

On Tue, 2003-02-04 at 13:29, Christoph Hellwig wrote:
> --- 1.64/drivers/scsi/scsi_lib.c	Tue Jan 28 23:09:29 2003
> +++ edited/drivers/scsi/scsi_lib.c	Tue Feb  4 20:19:00 2003
> @@ -35,7 +35,6 @@
>  }; 	
>  #undef SP
>  
> -struct scsi_core_data *scsi_core;
>  
>  /*
>   * Function:    scsi_insert_special_cmd()
> @@ -814,9 +813,10 @@
>  		SCpnt = (Scsi_Cmnd *) req->special;
>  		SRpnt = (Scsi_Request *) req->special;
>  		
> -		if( SRpnt->sr_magic == SCSI_REQ_MAGIC ) {
> -			SCpnt = scsi_getset_command(SRpnt->sr_device,
> -						    GFP_ATOMIC);
> +		if (SRpnt->sr_magic == SCSI_REQ_MAGIC) {
> +			if (SDpnt->device_busy >= SDpnt->queue_depth)
> +				return BLKPREP_DEFER;
> +			SCpnt = scsi_get_command(SRpnt->sr_device, GFP_ATOMIC);

Actually, I don't necessarily think we want to do this.

I think we should throttle in the request_fn not in the prep_fn.  The
reason is the way the block queue works:  If we have a prepped request
ready to roll, it will go straight through the request fn (without
sending it back through prep again).  Thus, we can have a fully prepared
command ready for immediate issue as soon as the device returns one of
its slots and therefore we keep the pipeline packed as tightly as
possible given the maximum number of outstanding commands constraint. 
It also means that we have all the memory allocations completed by the
time we try to issue the command, rather than trying the memory
allocations as part of the prep function for the next issue.

James