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 453811 - [RFE] Backport per device dirty thresholds
Summary: [RFE] Backport per device dirty thresholds
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Peter Zijlstra
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks: 533192 729758
TreeView+ depends on / blocked
 
Reported: 2008-07-02 18:05 UTC by Bryn M. Reeves
Modified: 2018-11-14 17:17 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-12 17:15:05 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Bryn M. Reeves 2008-07-02 18:05:07 UTC
Description of problem:
Upstream moved to having separate per-device dirty limit thresholds in 2.6.24.

Having per-BDI limits avoids a number of problematic situations; for example an
unresponsive network file system can cause other file systems to stall.

This was merged in commit 04fbfdc14e5f48463820d6b9807daa5e9c92c51f:

Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Tue Oct 16 23:25:50 2007 -0700

    mm: per device dirty threshold
    
    Scale writeback cache per backing device, proportional to its writeout speed.
    
    By decoupling the BDI dirty thresholds a number of problems we currently have
    will go away, namely:
    
     - mutual interference starvation (for any number of BDIs);
     - deadlocks with stacked BDIs (loop, FUSE and local NFS mounts).
    
    It might be that all dirty pages are for a single BDI while other BDIs are
    idling. By giving each BDI a 'fair' share of the dirty limit, each one can have
    dirty pages outstanding and make progress.
    
    A global threshold also creates a deadlock for stacked BDIs; when A writes to
    B, and A generates enough dirty pages to get throttled, B will never start
    writeback until the dirty pages go away. Again, by giving each BDI its own
    'independent' dirty limit, this problem is avoided.
    
    So the problem is to determine how to distribute the total dirty limit across
    the BDIs fairly and efficiently. A DBI that has a large dirty limit but does
    not have any dirty pages outstanding is a waste.
    
    What is done is to keep a floating proportion between the DBIs based on
    writeback completions. This way faster/more active devices get a larger share
    than slower/idle devices.
    
    [akpm@linux-foundation.org: fix warnings]
    [hugh@veritas.com: Fix occasional hang when a task couldn't get out of
balance_dirty_pages]
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Hugh Dickins <hugh@veritas.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>



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

How reproducible:
100%

Steps to Reproduce:
(One way...)
1. Mount a writable NFS mount somewhere
2. create 20 threads doing writes on this fs
3. stop the NFS server
4. dd if /dev/zero of /some/local/path bs 1024 count 10000
  
Actual results:
dd eventually stalls due to I/O throttling.

Expected results:
dd is not affected by throttling due to the unavailable NFS volume.

Additional info:

Comment 8 RHEL Product and Program Management 2009-02-16 15:28:05 UTC
Updating PM score.

Comment 15 RHEL Product and Program Management 2010-12-07 09:51:08 UTC
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.6 and Red Hat does not plan to fix this issue the currently developed update.

Contact your manager or support representative in case you need to escalate this bug.

Comment 16 RHEL Product and Program Management 2011-06-20 21:10:12 UTC
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.7 and Red Hat does not plan to fix this issue the currently developed update.

Contact your manager or support representative in case you need to escalate this bug.

Comment 17 Sayan Saha 2011-08-12 17:15:05 UTC
Thank you for submitting a feature request to be considered for inclusion in Red Hat Enterprise Linux enterprise operating system. After consideration, Red Hat does not plan to incorporate the suggested capability in a future release of Red Hat Enterprise Linux.  If you would like Red Hat to re-consider your feature request, please re-open the feature request via appropriate support channels and provide additional supporting details about the importance of this feature.


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