Bug 453811 - [RFE] Backport per device dirty thresholds
[RFE] Backport per device dirty thresholds
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Peter Zijlstra
Red Hat Kernel QE team
: FutureFeature, Triaged
Depends On:
Blocks: 533192 554476 729758
  Show dependency treegraph
 
Reported: 2008-07-02 14:05 EDT by Bryn M. Reeves
Modified: 2014-08-11 01:40 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-12 13:15:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bryn M. Reeves 2008-07-02 14:05:07 EDT
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 10:28:05 EST
Updating PM score.
Comment 15 RHEL Product and Program Management 2010-12-07 04:51:08 EST
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 17:10:12 EDT
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 13:15:05 EDT
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.