[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130815042930.GO6023@dastard>
Date: Thu, 15 Aug 2013 14:29:30 +1000
From: Dave Chinner <david@...morbit.com>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>,
linux-fsdevel@...r.kernel.org, xfs@....sgi.com,
linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>,
LKML <linux-kernel@...r.kernel.org>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Andy Lutomirski <luto@...capital.net>
Subject: Re: page fault scalability (ext3, ext4, xfs)
On Wed, Aug 14, 2013 at 07:24:01PM -0700, Andi Kleen wrote:
> > And FWIW, it's no secret that XFS has more per-operation overhead
> > than ext4 through the write path when it comes to allocation, so
> > it's no surprise that on a workload that is highly dependent on
> > allocation overhead that ext4 is a bit faster....
>
> This cannot explain a worse scaling curve though?
The scaling curve is pretty much identical. The difference in
performance will be the overhead of timestamp updates through
the transaction subsystems of the filesystems.
> w-i-s is all about scaling.
Sure, but scaling *what*? It's spending all it's time in the
filesystem through the .page_mkwrite path. It's not a page fault
scaling test - it's a filesystem overwrite test that uses mmap.
Indeed, I bet if you replace the mmap() with a write(fd, buf, 4096)
loop, you'd get almost identical behaviour from the filesystems.
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists