From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nikolaus Rath Subject: Re: [PATCH 0/10] fuse: An attempt to implement a write-back cache policy Date: Thu, 05 Jul 2012 22:04:04 -0400 Message-ID: <8762a1odbf.fsf@vostro.rath.org> References: <4FF3156E.8030109@parallels.com> <87a9zg1b7q.fsf@vostro.rath.org> <4FF3EC9B.6030605@parallels.com> <4FF59174.1070102@rath.org> <4FF59FF5.4030601@parallels.com> <4FF5A4B7.4010705@rath.org> <4FF5A5F3.3030707@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "fuse-devel\@lists.sourceforge.net" , linux-fsdevel To: Pavel Emelyanov Return-path: Received: from ebox.rath.org ([173.255.235.238]:40857 "EHLO ebox.rath.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754935Ab2GFCEM convert rfc822-to-8bit (ORCPT ); Thu, 5 Jul 2012 22:04:12 -0400 In-Reply-To: <4FF5A5F3.3030707@parallels.com> (Pavel Emelyanov's message of "Thu, 05 Jul 2012 18:34:27 +0400") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Pavel Emelyanov writes: >>>> With kernel 3.2: >>>> >>>> Blocksize: 4k >>>> 131072000 bytes (131 MB) copied, 7.76037 s, 16.9 MB/s >>>> >>> >>> [snip] >>> >>>> >>>> However, I suspect that most of the gain is really because with th= e >>>> patch most of the data is still in the kernel cache when dd finish= es 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 r= elates to >>> it gets flushed to the userspace! This is due to how FUSE write req= uests are >>> served. >>> >>> That said -- you've already measured writeback with flush :) >>=20 >>=20 >> But then how is it possible that there is such a big difference even >> when using 128kb blocks? >>=20 >> Kernel 3.2: >> 131072000 bytes (131 MB) copied, 2.10194 s, 62.4 MB/s >>=20 >> Kernel 3.5-pre: >> Blocksize: 128k >> 131072000 bytes (131 MB) copied, 0.51943 s, 252 MB/s >>=20 >> I would think that it both cases the FUSE daemon gets the data in 12= 8 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 sid= e > logs (if any). > >> 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, bu= t 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 --=20 =C2=BBTime flies like an arrow, fruit flies like a Banana.=C2=AB 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