lkml.org 
[lkml]   [2017]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/19] fs: rework and optimize i_version handling in filesystems
This is great, thanks.

On Wed, Dec 13, 2017 at 09:19:58AM -0500, Jeff Layton wrote:
> With this, we reduce inode metadata updates across all 3 filesystems
> down to roughly the frequency of the timestamp granularity, particularly
> when it's not being queried (the vastly common case).
>
> The pessimal workload here is 1 byte writes, and it helps that
> significantly. Of course, that's not what we'd consider a real-world
> workload.
>
> A tiobench-example.fio workload also shows some modest performance
> gains, and I've gotten mails from the kernel test robot that show some
> significant performance gains on some microbenchmarks (case-msync-mt in
> the vm-scalability testsuite to be specific), with an earlier version of
> this set.
>
> With larger writes, the gains with this patchset mostly vaporize,
> but it does not seem to cause performance to regress anywhere, AFAICT.
>
> I'm happy to run other workloads if anyone can suggest them.
>
> At this point, the patchset works and does what it's expected to do in
> my own testing. It seems like it's at least a modest performance win
> across all 3 major disk-based filesystems. It may also encourage others
> to implement i_version as well since it reduces the cost.

Do you have an idea what the remaining cost is?

Especially in the ext4 case, are you still able to measure any
difference in performance between the cases where i_version is turned on
and off, after these patches?

>
> [1]: On ext4 it must be turned on with the i_version mount option,
> mostly due to fears of incurring this impact, AFAICT.

So xfs and btrfs both have i_version updates on by default at this
point? (Assuming the filesystem's created with recent enough tools,
etc.)

--b.

\
 
 \ /
  Last update: 2017-12-13 16:06    [W:0.382 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site