Bug 146050 - linux-iscsi per-lun queueing limits are small at 12 IOs per lun
Summary: linux-iscsi per-lun queueing limits are small at 12 IOs per lun
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Mike Christie
QA Contact: Brock Organ
Whiteboard: RHEL3U7NAK
Keywords: FutureFeature
Depends On:
Blocks: 170417
TreeView+ depends on / blocked
Reported: 2005-01-24 22:40 UTC by Dave Wysochanski
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 19:08:55 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Dave Wysochanski 2005-01-24 22:40:06 UTC
Description of problem:
The file iscsi-limits.h specifies a low number for ISCSI_CMDS_PER_LUN
(currently 12). This will impact performance when IOs take longer to
complete on a target (i.e. consider the case of random reads), and the
initiator would benefit from increasing this beyond 12.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:
Reduced performance with higher latency IO workloads (e.g. random IO)

Expected results:
Better performance with higher latency IO workloads (e.g. random IO)

Additional info:
Fix has already been checked into sourceforge 3-6 branch to increase
IOs per LUN from 12 to 32.

Since we're seeing lockups with RHEL3, U4 kernel (see bugzilla
145818), we probably need to tread more carefully here, as this has
the potential to change the memory consumption characteristics of the
iscsi driver, and potentially lead to more problems.  Note that this
is not a request to increase the can_queue value, so it might not be a
big deal.  However, it needs to be fully tested and not just put in
there without much testing.

Comment 1 Tom Coughlan 2005-01-25 02:41:23 UTC
Hi Dave, this request is on my list for U5. I have already started
testing it, and will continue, with an eye on the outcome of BZ 145818.

Comment 2 Tom Coughlan 2005-03-08 15:45:39 UTC
I decided not to make this change because it could make the problem in BZ 145818
worse. Once we have (at least a partial) workaround for BZ 145818, then we will
increase the queue depth.

Comment 3 Dave Wysochanski 2005-09-01 18:53:54 UTC
FYI - just had another internal (netapp) customer asking about this.

Comment 7 RHEL Product and Program Management 2007-10-19 19:08:55 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

Note You need to log in before you can comment on or make changes to this bug.