Re: write performance difference 3.18.21/git f2fs

[Marc Lehmann <schmorp@schmorp.de>]

On Tue, Sep 29, 2015 at 04:13:10PM -0700, Jaegeuk Kim <jaegeuk@kernel.org> wrote:
> > First thing, the allocation-failure-on-mount is still in the backported 3.18
> > f2fs module. If it's supposed to be gone in that version, it's not working:
> > 
> > http://ue.tst.eu/a1bc4796012bd7191ab2ada566d4cd22.txt
> 
> Oops, it seems I missed some other allocations too.
> Could you pull the v3.18 again? I changed the patch.

Hmm, I don't see any relevant change in the log, but I will use the newest
version.

> > (event tracing is cool btw., thanks for showing me :)
> 
> Thank you for the below traces.
> I have two suspicious things from the traces where:
> 
> 1. several inline_data conversion of existing files
> Could you test -o noinline_data and share its trace too?

WOW, THAT HELPED A LOT. While the peak throughput seems quite a bit lower
than 3.18 stock (seems, because this might be caused by less peaky, more
smooth, writes - I am only looking at it with my eyes), it could keep up
with the reading side easily, and performance didn't degrade so far. The
test continues, but here is the trace for the first 368GB:

http://data.plan9.de/f2fs.s64.noinline.trace.xz

I had a cursory look at the previous traces, and didn't see any obvious
problem (if anything, git f2fs seems to leave fewer gaps). However, both
versions do leave quite a few gaps.

I wanted to look at reordering, which might be a problem, too, but didn't
get to that.

Obviously, inline_data was the culprit for the especially bad performance.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp@schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

------------------------------------------------------------------------------