All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex,Shi" <alex.shi@intel.com>
To: Jens Axboe <jaxboe@fusionio.com>
Cc: "Li, Shaohua" <shaohua.li@intel.com>,
	"James.Bottomley@hansenpartnership.com" 
	<James.Bottomley@hansenpartnership.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Chen, Tim C" <tim.c.chen@intel.com>
Subject: Re: Perfromance drop on SCSI hard disk
Date: Thu, 19 May 2011 16:47:31 +0800	[thread overview]
Message-ID: <1305794851.22968.161.camel@debian> (raw)
In-Reply-To: <1305793580.22968.155.camel@debian>

On Thu, 2011-05-19 at 16:26 +0800, Alex,Shi wrote:
> > I will queue up the combined patch, it looks fine from here as well.
> > 
> 
> When I have some time to study Jens and shaohua's patch today. I find a
> simpler way to resolved the re-enter issue on starved_list. Following
> Jens' idea, we can just put the starved_list device into kblockd if it
> come from __scsi_queue_insert(). 
> It can resolve the re-enter issue and recover performance totally, and
> need not a work_struct in every scsi_device. The logic/code also looks a
> bit simpler. 
> What's your opinion of this? 

BTW, Jens, this patch is against on latest kernel, 2.6.39. 
> 
> 
> Signed-off-by: Alex Shi <alex.shi@intel.com>
> ---
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index ec1803a..de7c569 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -74,6 +74,8 @@ struct kmem_cache *scsi_sdb_cache;
>   */
>  #define SCSI_QUEUE_DELAY	3
>  
> +static void scsi_run_queue_async(struct request_queue *q);
> +
>  /*
>   * Function:	scsi_unprep_request()
>   *
> @@ -159,7 +161,7 @@ static int __scsi_queue_insert(struct scsi_cmnd *cmd, int reason, int unbusy)
>  	blk_requeue_request(q, cmd->request);
>  	spin_unlock_irqrestore(q->queue_lock, flags);
>  
> -	kblockd_schedule_work(q, &device->requeue_work);
> +	scsi_run_queue_async(q);
>  
>  	return 0;
>  }
> @@ -395,7 +397,7 @@ static inline int scsi_host_is_busy(struct Scsi_Host *shost)
>   * Notes:	The previous command was completely finished, start
>   *		a new one if possible.
>   */
> -static void scsi_run_queue(struct request_queue *q)
> +static void __scsi_run_queue(struct request_queue *q, bool async)
>  {
>  	struct scsi_device *sdev = q->queuedata;
>  	struct Scsi_Host *shost;
> @@ -435,30 +437,35 @@ static void scsi_run_queue(struct request_queue *q)
>  				       &shost->starved_list);
>  			continue;
>  		}
> -
> -		spin_unlock(shost->host_lock);
> -		spin_lock(sdev->request_queue->queue_lock);
> -		__blk_run_queue(sdev->request_queue);
> -		spin_unlock(sdev->request_queue->queue_lock);
> -		spin_lock(shost->host_lock);
> +		if (async)
> +			blk_run_queue_async(sdev->request_queue);
> +		else {
> +			spin_unlock(shost->host_lock);
> +			spin_lock(sdev->request_queue->queue_lock);
> +			__blk_run_queue(sdev->request_queue);
> +			spin_unlock(sdev->request_queue->queue_lock);
> +			spin_lock(shost->host_lock);
> +		}
>  	}
>  	/* put any unprocessed entries back */
>  	list_splice(&starved_list, &shost->starved_list);
>  	spin_unlock_irqrestore(shost->host_lock, flags);
>  
> -	blk_run_queue(q);
> +	if (async)
> +		blk_run_queue_async(q);
> +	else
> +		blk_run_queue(q);
>  }
>  
> -void scsi_requeue_run_queue(struct work_struct *work)
> +static void scsi_run_queue(struct request_queue *q)
>  {
> -	struct scsi_device *sdev;
> -	struct request_queue *q;
> -
> -	sdev = container_of(work, struct scsi_device, requeue_work);
> -	q = sdev->request_queue;
> -	scsi_run_queue(q);
> +	__scsi_run_queue(q, false);
>  }
>  
> +static void scsi_run_queue_async(struct request_queue *q)
> +{
> +	__scsi_run_queue(q, true);
> +}
>  /*
>   * Function:	scsi_requeue_command()
>   *
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 58584dc..087821f 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -242,7 +242,6 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
>  	int display_failure_msg = 1, ret;
>  	struct Scsi_Host *shost = dev_to_shost(starget->dev.parent);
>  	extern void scsi_evt_thread(struct work_struct *work);
> -	extern void scsi_requeue_run_queue(struct work_struct *work);
>  
>  	sdev = kzalloc(sizeof(*sdev) + shost->transportt->device_size,
>  		       GFP_ATOMIC);
> @@ -265,7 +264,6 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
>  	INIT_LIST_HEAD(&sdev->event_list);
>  	spin_lock_init(&sdev->list_lock);
>  	INIT_WORK(&sdev->event_work, scsi_evt_thread);
> -	INIT_WORK(&sdev->requeue_work, scsi_requeue_run_queue);
>  
>  	sdev->sdev_gendev.parent = get_device(&starget->dev);
>  	sdev->sdev_target = starget;
> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> index dd82e02..2d3ec50 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -169,7 +169,6 @@ struct scsi_device {
>  				sdev_dev;
>  
>  	struct execute_work	ew; /* used to get process context on put */
> -	struct work_struct	requeue_work;
>  
>  	struct scsi_dh_data	*scsi_dh_data;
>  	enum scsi_device_state sdev_state;
> 



  reply	other threads:[~2011-05-19  8:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-10  6:40 Perfromance drop on SCSI hard disk Alex,Shi
2011-05-10  6:52 ` Shaohua Li
2011-05-12  0:36   ` Shaohua Li
2011-05-12 20:29 ` Jens Axboe
2011-05-13  0:11   ` Alex,Shi
2011-05-13  0:48   ` Shaohua Li
2011-05-13  3:01     ` Shaohua Li
2011-05-16  8:04       ` Shaohua Li
2011-05-16  8:37         ` Alex,Shi
2011-05-17  6:09           ` Alex,Shi
2011-05-17  7:20             ` Jens Axboe
2011-05-19  8:26               ` Alex,Shi
2011-05-19  8:47                 ` Alex,Shi [this message]
2011-05-19 18:27                 ` Jens Axboe
2011-05-20  0:22                   ` Alex,Shi
2011-05-20  0:40                     ` Shaohua Li
2011-05-20  5:17                       ` Alex,Shi

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=1305794851.22968.161.camel@debian \
    --to=alex.shi@intel.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=jaxboe@fusionio.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaohua.li@intel.com \
    --cc=tim.c.chen@intel.com \
    /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.