[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120702143215.GS14154@suse.de>
Date: Mon, 2 Jul 2012 15:32:15 +0100
From: Mel Gorman <mgorman@...e.de>
To: Christoph Hellwig <hch@...radead.org>
Cc: Dave Chinner <david@...morbit.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
xfs@....sgi.com
Subject: Re: [MMTests] IO metadata on XFS
On Mon, Jul 02, 2012 at 02:32:26AM -0400, Christoph Hellwig wrote:
> > It increases the CPU overhead (dirty_inode can be called up to 4
> > times per write(2) call, IIRC), so with limited numbers of
> > threads/limited CPU power it will result in lower performance. Where
> > you have lots of CPU power, there will be little difference in
> > performance...
>
> When I checked it it could only be called twice, and we'd already
> optimize away the second call. I'd defintively like to track down where
> the performance changes happend, at least to a major version but even
> better to a -rc or git commit.
>
By all means feel free to run the test yourself and run the bisection :)
It's rare but on this occasion the test machine is idle so I started an
automated git bisection. As you know the milage with an automated bisect
varies so it may or may not find the right commit. Test machine is sandy so
http://www.csn.ul.ie/~mel/postings/mmtests-20120424/global-dhp__io-metadata-xfs/sandy/comparison.html
is the report of interest. The script is doing a full search between v3.3 and
v3.4 for a point where average files/sec for fsmark-single drops below 25000.
I did not limit the search to fs/xfs on the off-chance that it is an
apparently unrelated patch that caused the problem.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists