xfs
[Top] [All Lists]

Re: page fault scalability (ext3, ext4, xfs)

To: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
Subject: Re: page fault scalability (ext3, ext4, xfs)
From: Theodore Ts'o <tytso@xxxxxxx>
Date: Thu, 15 Aug 2013 15:31:22 -0400
Cc: linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, Jan Kara <jack@xxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, david@xxxxxxxxxxxxx, Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>, Andi Kleen <ak@xxxxxxxxxxxxxxx>, Andy Lutomirski <luto@xxxxxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1376595082; bh=ZVKxmaRk1TnfbR6rzGhiJCOawIP2uDDbnOCg9rgAlQ4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ukmOzvk5b0In+H3omHXFQBacEBCLcLTwTsCE/vNnroRhhLbo71hZkz/Srf5Ul0/j4 Roop4/Fq18YwPjJYSnIqRgzphDRYZawvHlt04lscl7gE+9OlHYfEg4yb1/F8c3PxBl FNF8pmrvD/9dfv3QGL2OK7qASq24NeLH+Pa5hsP8=
In-reply-to: <520D13A5.2070808@xxxxxxxxxxxxxxx>
Mail-followup-to: Theodore Ts'o <tytso@xxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, Jan Kara <jack@xxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, david@xxxxxxxxxxxxx, Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>, Andi Kleen <ak@xxxxxxxxxxxxxxx>, Andy Lutomirski <luto@xxxxxxxxxxxxxx>
References: <520BB9EF.5020308@xxxxxxxxxxxxxxx> <20130815150506.GA10415@xxxxxxxxx> <520D13A5.2070808@xxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Aug 15, 2013 at 10:45:09AM -0700, Dave Hansen wrote:
> 
> I _believe_ this is because the block allocation is occurring during the
> warmup, even in those numbers I posted previously.  will-it-scale forks
> things off early and the tests spend most of their time in those while
> loops.  Each "page fault handled" (the y-axis) is a trip through the
> while loop, *not* a call to testcase().

Ah, OK.  Sorry, I misinterpreted what was going on.

So basically, what we have going on in the test is (a) we're bumping
i_version and/or mtime, and (b) the munmap() implies an msync(), so
writeback is happening in the background concurrently with the write
page faults, and we may be (actually, almost certainly) seeing some
interference between the writeback and the page_mkwrite operations.

That implies that if you redid the test using a ramdisk, which will
significantly speed up the writeback and overhead caused by the
journal transactions for the metadata updates, the results might very
well be different.

Cheers,

                                                - Ted

<Prev in Thread] Current Thread [Next in Thread>