lkml.org 
[lkml]   [2010]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 00/13] IO-less dirty throttling v2
    On Wed, Nov 17, 2010 at 03:03:30PM -0800, Andrew Morton wrote:
    > On Wed, 17 Nov 2010 12:27:20 +0800
    > Wu Fengguang <fengguang.wu@intel.com> wrote:
    >
    > > On a simple test of 100 dd, it reduces the CPU %system time from 30% to 3%, and
    > > improves IO throughput from 38MB/s to 42MB/s.
    >
    > The changes in CPU consumption are remarkable. I've looked through the
    > changelogs but cannot find mention of where all that time was being
    > spent?

    In the writeback path, mostly because every CPU is trying to run
    writeback at the same time and causing contention on locks and
    shared structures in the writeback path. That no longer happens
    because writeback is only happening from one thread instead of from
    all CPUs at once.

    This is one of the reasons why I want this series to be sorted out
    before we start to consider scalability of the writeback lists and
    locking - controlling the level of writeback parallelism provides a
    major reduction in writeback lock contention and indicates that the
    next bottleneck we really need to solve is bdi-flusher thread
    parallelism...

    > How well have these changes been tested with NFS?

    Next on my list (just doing some ext4 sanity testing).

    > The changes are complex and will probably do Bad Things for some
    > people. Does the code implement sufficient
    > debug/reporting/instrumentation to enable you to diagnose, understand
    > and fix people's problems in the minimum possible time? If not, please
    > add that stuff. Just go nuts with it. Put it in debugfs, add /*
    > DELETEME */ comments and we can pull it all out again in half a year or
    > so.
    >
    > Or perhaps litter the code with temporary tracepoints, provided we can
    > come up with a way for our testers to trivially gather their output.

    I think tracepoints are the way to go - I've been asking XFS users
    to send me trace dumps for anyhting non-trivial recently. I've been
    able to understand the cause of their problems without having to
    reproduce the problem locally, which has been a big help....

    Cheers,

    Dave.
    --
    Dave Chinner
    david@fromorbit.com


    \
     
     \ /
      Last update: 2010-11-18 03:09    [W:3.372 / U:1.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site