Bug 146050

Summary: linux-iscsi per-lun queueing limits are small at 12 IOs per lun
Product: Red Hat Enterprise Linux 3 Reporter: Dave Wysochanski <davidw>
Component: kernelAssignee: Mike Christie <mchristi>
Status: CLOSED WONTFIX QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: 157070.alewis, coughlan, davidw, kanderso, petrides, rkenna
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: RHEL3U7NAK
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 19:08:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 170417    

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):
3.6.2-4


How reproducible:
N/A


Steps to Reproduce:
N/A

  
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 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:
http://www.redhat.com/security/updates/errata/
 
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.