All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: James Bottomley <jbottomley@parallels.com>,
	linux-scsi@vger.kernel.org,
	Sumit Saxena <sumit.saxena@avagotech.com>
Subject: Re: [PATCH] megaraid_sas: Enable shared tag map
Date: Tue, 30 Sep 2014 11:08:17 +0200	[thread overview]
Message-ID: <542A7301.1060400@suse.de> (raw)
In-Reply-To: <20140930074329.GA10290@infradead.org>

On 09/30/2014 09:43 AM, Christoph Hellwig wrote:
> On Mon, Sep 29, 2014 at 01:47:52PM +0200, Hannes Reinecke wrote:
>> Megaraid_sas uses a shared pool of commands per HBA, so we
>> should be enabling a shared tag map.
>> This will allow the I/O scheduler to make better scheduling
>> decisions and will avoid BUSY states in the driver.
> 
> What exact problem did you see?  Do you have a link to a bugzilla entry
> or similar?  Was this observed on real hardware or your qemu emulation?
> 
Well, _actually_ I just did it so that I could get the tag number
for my printk patchset :-)

But there is an underlying reason:
megaraid_sas uses an internal frame pool of a fixed size.
Once that's exhausted it cannot queue any more commands, and need to
return busy.
But as this is a per-host command pool all LUNs have to shared the
same frame pool, and the driver uses heuristics (ie 1/4 of the pool
size) to set cmd_per_lun. So if you have more than 4 LUNs you'll run
into issues as the pool can become exhausted.
Hence I thought it would be good to expose this to the block layer
so that we can avoid BUSY states in the driver.


>>
>> Signed-off-by: Hannes Reinecke <hare@suse.de>
>> ---
>>  drivers/scsi/megaraid/megaraid_sas_base.c | 34 ++++++++++++++++++++++++++++++-
>>  1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index f6a69a3..996fa9a 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -1659,7 +1659,7 @@ static int megasas_slave_configure(struct scsi_device *sdev)
>>  	*/
>>  	blk_queue_rq_timeout(sdev->request_queue,
>>  		MEGASAS_DEFAULT_CMD_TIMEOUT * HZ);
>> -
>> +	sdev->tagged_supported = 1;
> 
>> +	/* We have a shared tag map, so TCQ is always supported */
>> +	sdev->tagged_supported = 1;
>> +
> 
> Why doesn't the device return the proper data in the INQUIRY response?
> 
> And more importantly why do you want to do this twice?
> 
Bah, Typo.

>>  	instance = megasas_lookup_instance(sdev->host->host_no);
>>  	if (sdev->channel < MEGASAS_MAX_PD_CHANNELS) {
>>  		/*
>> @@ -1677,13 +1681,20 @@ static int megasas_slave_alloc(struct scsi_device *sdev)
>>  			sdev->id;
>>  		if (instance->pd_list[pd_index].driveState ==
>>  					MR_PD_STATE_SYSTEM) {
>> +			scsi_activate_tcq(sdev, MEGASAS_DEFAULT_CMD_PER_LUN);
>>  			return 0;
>>  		}
>>  		return -ENXIO;
>>  	}
>> +	scsi_activate_tcq(sdev, MEGASAS_DEFAULT_CMD_PER_LUN);
>>  	return 0;
> 
> Please refactor the code so that the first case falls through to the
> second, something like:
> 
> 
> 		if (instance->pd_list[pd_index].driveState !=
> 					MR_PD_STATE_SYSTEM)
> 			return -ENXIO;
> 	}
> 
> 	scsi_activate_tcq(sdev, MEGASAS_DEFAULT_CMD_PER_LUN);
> 	return 0;
> 
Okay, will be doing it.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-09-30  9:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-29 11:47 [PATCH] megaraid_sas: Enable shared tag map Hannes Reinecke
2014-09-29 16:52 ` Webb Scales
2014-09-29 17:08   ` James Bottomley
2014-09-30  7:43 ` Christoph Hellwig
2014-09-30  9:08   ` Hannes Reinecke [this message]
2014-10-01 18:51 ` Webb Scales
2014-10-01 21:10   ` Christoph Hellwig
2014-10-02  6:51     ` Hannes Reinecke
2014-10-02  9:19       ` Christoph Hellwig
2014-10-02  9:50         ` Hannes Reinecke
2014-10-02 11:36           ` Christoph Hellwig
2014-10-02 12:00             ` Hannes Reinecke
2014-10-02 14:32               ` Christoph Hellwig
2014-10-02 12:05       ` James Bottomley
2014-10-02 12:14         ` Hannes Reinecke
2014-10-02 13:06           ` James Bottomley

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=542A7301.1060400@suse.de \
    --to=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=jbottomley@parallels.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sumit.saxena@avagotech.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.