[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090922104915.GA1649@localhost>
Date: Tue, 22 Sep 2009 18:49:15 +0800
From: Wu Fengguang <fengguang.wu@...el.com>
To: Shaohua Li <shaohua.li@...el.com>
Cc: linux-kernel@...r.kernel.org, richard@....demon.co.uk,
a.p.zijlstra@...llo.nl, jens.axboe@...cle.com,
akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
Chris Mason <chris.mason@...cle.com>
Subject: Re: regression in page writeback
Shaohua,
On Tue, Sep 22, 2009 at 01:49:13PM +0800, Li, Shaohua wrote:
> Hi,
> Commit d7831a0bdf06b9f722b947bb0c205ff7d77cebd8 causes disk io regression
> in my test.
> My system has 12 disks, each disk has two partitions. System runs fio sequence
> write on all partitions, each partion has 8 jobs.
> 2.6.31-rc1, fio gives 460m/s disk io
> 2.6.31-rc2, fio gives about 400m/s disk io. Revert the patch, speed back to
> 460m/s
>
> Under latest git: fio gives 450m/s disk io; If reverting the patch, the speed
> is 484m/s.
>
> With the patch, fio reports less io merge and more interrupts. My naive
> analysis is the patch makes balance_dirty_pages_ratelimited_nr() limits
> write chunk to 8 pages and then soon go to sleep in balance_dirty_pages(),
> because most time the bdi_nr_reclaimable < bdi_thresh, and so when write
> the pages out, the chunk is 8 pages long instead of 4M long. Without the patch,
> thread can write 8 pages and then move some pages to writeback, and then
> continue doing write. The patch seems to break this.
Do you have trace/numbers for above descriptions?
> Unfortunatelly I can't figure out a fix for this issue, hopefully
> you have more ideas.
Attached is a very verbose writeback debug patch, hope it helps and
won't disturb the workload a lot :)
Thanks,
Fengguang
View attachment "writeback-debug-2.6.31.patch" of type "text/x-diff" (5469 bytes)
Powered by blists - more mailing lists