Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 156378 - [EMC RHEL 5.0.0 FEAT] kernel dm: Should the QUEUE_CLUSTER_FLAG of a target device's request queue be included in the device-mapper io_restrictions semantics?
Summary: [EMC RHEL 5.0.0 FEAT] kernel dm: Should the QUEUE_CLUSTER_FLAG of a target de...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Alasdair Kergon
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-29 15:41 UTC by Ed Goggin
Modified: 2007-11-30 22:07 UTC (History)
13 users (show)

Fixed In Version: 5.0.0
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-10-11 12:37:23 UTC


Attachments (Terms of Use)
dm-table-queue-cluster.patch (deleted)
2006-02-15 16:18 UTC, Alasdair Kergon
no flags Details | Diff

Description Ed Goggin 2005-04-29 15:41:11 UTC
Description of problem:

It appears the the request queue for ALL device-mapper mapped devices
has the QUEUE_CLUSTER_FLAG reset thereby disabling the clustering
of physically contiguous pages into a single io segment.  This can
lead to premature exhaustion of the request queue's maximum hardware
segment count for bios sent to mapped devices.

Seems like a natural enhancement to the device-mapper io_restrictions
structure include a field to indicate whether or not I/O may be clustered
as indicated by the setting of the QUEUE_CLUSTER_FLAG bit of the queue_flags 
field of the request_queue structures for the collective set of target devices.

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

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Ed Goggin 2005-04-29 16:02:22 UTC
The embedded Qlogic FC HBA driver enables page clustering.  Likely
that all of the FC HBA drivers do.  Should only affect large bios
since at least the Qlogic FC HBA driver is configured to support
an io up to 255 segments.  This should handle just shy of a 1MB bio.

Comment 2 Alasdair Kergon 2005-05-04 14:50:16 UTC
Need to check how this would interact with the bio splitting and suspend code. 
There may be a case for deciding whether or not to set it according to the
characteristics of the table.

Comment 3 Heather Conway 2005-08-30 18:22:32 UTC
Is this request being considered for incorporation into RHEL 4.0 U3?
Thanks.
-H

Comment 5 Heather Conway 2005-09-15 15:42:23 UTC
Is there an update on this Bugzilla?
Thanks.
-H

Comment 14 Heather Conway 2006-01-16 16:32:22 UTC
Hi Alasdair - have you had an opportunity to look into this enhancement 
request?  If so, do you have an update?
Thanks.
Heather


Comment 15 Alasdair Kergon 2006-02-15 15:32:15 UTC
Well Neil Brown has made a patch (which I'll attach and we can test for U4) but
I'm not sure it'll make much difference to performance because device-mapper
still requires I/O to be broken up into small pieces.  This is likely to need
block layer changes for which we should create a separate feature request to try
to address this issue in the RHEL5 (or might even have to be RHEL6) time frame.

Comment 16 Alasdair Kergon 2006-02-15 16:18:09 UTC
Created attachment 124691 [details]
dm-table-queue-cluster.patch

Unfortunately the structures in device-mapper.h weren't designed for extension
and the new 'no_cluster' field forms part of an important exposed structure -
struct dm_target - and this patch will break ABI.

If we decide it is worth putting this in RHEL4 U4, then we need to come up with
a workaround.

Comment 17 Alasdair Kergon 2006-03-15 16:55:53 UTC
I don't think it's worth doing a backport - propose letting the upstream change
filter down into RHEL5.

Comment 25 Jay Turner 2006-09-19 18:09:06 UTC
What's the status of this?  Did the changes land in RHEL5?

Comment 26 Alasdair Kergon 2006-10-10 15:15:15 UTC
Yes, they're in the upstream kernel RHEL5 kernel was derived from.

Comment 27 Jay Turner 2006-10-11 12:37:23 UTC
Closing out based on comment 26.


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