Re: [PATCH 0/10] fuse: An attempt to implement a write-back cache policy

Pavel Emelyanov [off-list ref] writes:

quoted

quoted

quoted

With kernel 3.2:

Blocksize: 4k
131072000 bytes (131 MB) copied, 7.76037 s, 16.9 MB/s

[snip]

quoted

However, I suspect that most of the gain is really because with the
patch most of the data is still in the kernel cache when dd finishes and
hasn't yet been received by the FUSE client.


Is there a way to force flushing of the fuse cache, so that I can
measure the time for dd + final flush?

Actually when dd closes an output file the whole page cache which relates to
it gets flushed to the userspace! This is due to how FUSE write requests are
served.

That said -- you've already measured writeback with flush :)

But then how is it possible that there is such a big difference even
when using 128kb blocks?

Kernel 3.2:
131072000 bytes (131 MB) copied, 2.10194 s, 62.4 MB/s

Kernel 3.5-pre:
Blocksize: 128k
131072000 bytes (131 MB) copied, 0.51943 s, 252 MB/s

I would think that it both cases the FUSE daemon gets the data in 128 kb
packets, so why the difference? Or is this due to some other change
between 3.2 and 3.5 that significantly increased FUSE performance?

I don't know for sure. Need to read an analyze the FUSE userspace side
logs (if any).

quoted

I can try the same test with the unpatched 3.5 tonight if that would be
of interest.

Yes, this can help.

Alright, here are the resulting transfer rates for 131 MB of data:

Blocksize    Kernel 3.2         3.5-pre          3.5-pre + patch
4k           16.2               31.5             23.8
8k           52.8               48.5             91.2
16k          59.1               46.8             136
32k          64.1               47.6             185
64k          71.3               50.9             217
96k          76.1               50.6             229
128k         62.4               76.5             252
256k         66.6               68.8             286
512k         54.1               55.1             290
1024k        78.7               68.5             294

There's up to 20 MB/s variation for a block size on successive runs, but
it's still obvious that the patch really makes a huge difference.
Thinking about it, it actually makes sense even for the block sizes
greater than 128 kb. Here the speedup probably comes from the fact that
the FUSE daemon can now process several chunks at the same time.


Please let me know if there is anything I can do to help get this
merged. The results look fantastic.

Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html