From: Jeff Moyer <jmoyer@redhat.com>
To: Jens Axboe <axboe@kernel.dk>, Asai Thambi S P <asamymuthupa@micron.com>
Cc: "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Sam Bradshaw <sbradshaw@micron.com>
Subject: Re: [PATCH 05/11] mtip32xx: Set block queue boundary variables
Date: Thu, 31 May 2012 14:40:22 -0400 [thread overview]
Message-ID: <x49hauwb3e1.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <4FC7B491.9030105@micron.com> (Asai Thambi S. P.'s message of "Thu, 31 May 2012 11:12:33 -0700")
>>>>> @@ -3631,7 +3631,11 @@ skip_create_disk:
>>>>> set_bit(QUEUE_FLAG_NONROT, &dd->queue->queue_flags);
>>>>> blk_queue_max_segments(dd->queue, MTIP_MAX_SG);
>>>>> blk_queue_physical_block_size(dd->queue, 4096);
>>>>> + blk_queue_max_hw_sectors(dd->queue, 0xffff);
>>>>> + blk_queue_max_segment_size(dd->queue, 0x400000);
>>>>> blk_queue_io_min(dd->queue, 4096);
>>>>> + dd->queue->nr_requests = 255;
>>>>
>>>> ->nr_requests isn't a boundary variable you set for the queue. It's set
>>>> by the core bits, or by the user via the sysfs interface.
>>>>
>>>> So you should not touch that from the driver.
>>>>
>>>
>>> Ok.
>>>
>>> I saw scsi lib module changing it, so thought of changing the value close to
>>> device queue depth.
>>
>> That's actually a fair point. What is the device queue depth for this
>> card?
>>
> 256
Jens, I actually think changing nr_requests makes sense; the only
question in my mind is where to do it. (There's no point in artificially
limiting the device by default.) IIRC, your general rule was to set this
value to 2x the device's queue depth. So, given that this driver
doesn't use the blk-tag interfaces, what do you think would be the
cleanest way to bump nr_requests in this (and the more general) case?
Cheers,
Jeff
next prev parent reply other threads:[~2012-05-31 18:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-30 1:42 Asai Thambi S P
2012-05-31 6:43 ` Jens Axboe
2012-05-31 15:56 ` Asai Thambi S P
2012-05-31 17:12 ` Jeff Moyer
2012-05-31 18:12 ` Asai Thambi S P
2012-05-31 18:40 ` Jeff Moyer [this message]
2012-06-01 6:01 ` Jens Axboe
2012-06-01 13:11 ` Jeff Moyer
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=x49hauwb3e1.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=asamymuthupa@micron.com \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=sbradshaw@micron.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®