[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.114 / U:30.316 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site