lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 31 May 2012 14:40:22 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Jens Axboe <axboe@...nel.dk>,
	Asai Thambi S P <asamymuthupa@...ron.com>
Cc:	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	Sam Bradshaw <sbradshaw@...ron.com>
Subject: Re: [PATCH 05/11] mtip32xx: Set block queue boundary variables

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ