[lkml]   [2008]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 0/7] cpuset writeback throttling
    On Thu, Oct 30, 2008 at 12:23:10PM -0700, David Rientjes wrote:
    > Andrew,
    > This is the revised cpuset writeback throttling patchset posted to LKML
    > on Tuesday, October 27.
    > The comments from Peter Zijlstra have been addressed. His concurrent
    > page cache patchset is not currently in -mm, so we can still serialize
    > updating a struct address_space's dirty_nodes on its tree_lock. When his
    > patchset is merged, the patch at the end of this message can be used to
    > introduce the necessary synchronization.
    > This patchset applies nicely to 2.6.28-rc2-mm1 with the exception of the
    > first patch due to the alloc_inode() refactoring to inode_init_always() in
    > e9110864c440736beb484c2c74dedc307168b14e from linux-next and additions to
    > include/linux/cpuset.h from
    > oom-print-triggering-tasks-cpuset-and-mems-allowed.patch (oops :).
    > Please consider this for inclusion in the -mm tree.
    > A simple way of testing this change is to create a large file that exceeds
    > the amount of memory allocated to a specific cpuset. Then, mmap and
    > modify the large file (such as in the following program) while running a
    > latency sensitive task in a disjoint cpuset. Notice the writeout
    > throttling that doesn't interfere with the latency sensitive task.

    What sort of validation/regression testing has this been through?


    Dave Chinner

     \ /
      Last update: 2008-10-30 22:11    [W:0.028 / U:186.968 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site