LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: David Chinner <dgc@sgi.com>
Cc: Christoph Lameter <clameter@sgi.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [REGRESSION] 2.6.19/2.6.20-rc3 buffered write slowdown
Date: Thu, 11 Jan 2007 20:27:12 +1100	[thread overview]
Message-ID: <45A602F0.1090405@yahoo.com.au> (raw)
In-Reply-To: <20070111012404.GW33919298@melbourne.sgi.com>

David Chinner wrote:
> On Thu, Jan 11, 2007 at 12:08:10PM +1100, Nick Piggin wrote:

>>>So, what I've attached is three files which have both
>>>'vmstat 5' output and 'iostat 5 |grep dm-' output in them.
>>
>>Ahh, sorry to be unclear, I meant:
>>
>>  cat /proc/vmstat > pre
>>  run_test
>>  cat /proc/vmstat > post
> 
> 
> Ok, I'll get back to you on that one - even at 600+MB/s, writing 5TB
> of data takes some time....

OK, according to your vmstat deltas, you are doing an order of magnitude
more writeout off the LRU with 2.6.20-rc3 default than with the smaller
dirty_ratio (53GB of data vs 4GB of data). 2.6.18 does not have that stat,
unfortunately.

allocstall and direct reclaim are way down when the dirty ratio is lower,
but those numbers with vanilla 2.6.20-rc3 are comparable to 2.6.18, so
that shows that kswapd in 2.6.18 is probably also having trouble which may
mean it is also writing out a lot off the LRU.

You're not turning on zone_reclaim, by any chance, are you?

Otherwise, nothing jumps out at me yet. I'll have a bit of a look through
changelogs tomorrow. I guess it could be a pdflush or vmscan change (XFS,
maybe?).

Can you narrow it down at all?

THanks,
Nick

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

  reply	other threads:[~2007-01-11  9:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-10 22:37 David Chinner
2007-01-10 23:04 ` Christoph Lameter
2007-01-10 23:08   ` David Chinner
2007-01-10 23:12     ` Christoph Lameter
2007-01-10 23:18       ` David Chinner
2007-01-10 23:13     ` Nick Piggin
2007-01-11  0:31       ` David Chinner
2007-01-11  0:43         ` Christoph Lameter
2007-01-11  1:06           ` David Chinner
2007-01-11  1:40             ` Christoph Lameter
2007-01-11  2:57               ` David Chinner
2007-01-11  1:08         ` Nick Piggin
2007-01-11  1:24           ` David Chinner
2007-01-11  9:27             ` Nick Piggin [this message]
2007-01-11 17:51               ` Christoph Lameter
2007-01-12  0:06                 ` Nick Piggin
2007-01-12  3:04                   ` Christoph Lameter
     [not found]           ` <20070111063555.GB33919298@melbourne.sgi.com>
2007-01-11  9:23             ` Nick Piggin
2007-01-11  1:11     ` David Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45A602F0.1090405@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=clameter@sgi.com \
    --cc=dgc@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --subject='Re: [REGRESSION] 2.6.19/2.6.20-rc3 buffered write slowdown' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).