linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikolaus Rath <Nikolaus@rath.org>
To: xemul@parallels.com
Cc: "fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org"
	<public-fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@plane.gmane.org>,
	linux-fsdevel
	<public-linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@plane.gmane.org>
Subject: Re: [PATCH 0/10] fuse: An attempt to implement a write-back cache policy
Date: Thu, 05 Jul 2012 09:07:00 -0400	[thread overview]
Message-ID: <4FF59174.1070102@rath.org> (raw)
In-Reply-To: <4FF3EC9B.6030605@parallels.com>



Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> writes:
>> While I try to get this to compile,
>
> That's good news! Thanks a lot!

Ok, I got it to compile and tested it by copying a large file into an
S3QL FUSE file system using different block sizes. At first glance,
things look fantastic.

With kernel 3.2:

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

Blocksize: 8k
131072000 bytes (131 MB) copied, 2.48469 s, 52.8 MB/s

Blocksize: 16k
131072000 bytes (131 MB) copied, 2.21868 s, 59.1 MB/s

Blocksize: 32k
131072000 bytes (131 MB) copied, 2.0455 s, 64.1 MB/s

Blocksize: 64k
131072000 bytes (131 MB) copied, 1.83897 s, 71.3 MB/s

Blocksize: 96k
131072000 bytes (131 MB) copied, 1.72298 s, 76.1 MB/s

Blocksize: 128k
131072000 bytes (131 MB) copied, 2.10194 s, 62.4 MB/s

Blocksize: 256k
131072000 bytes (131 MB) copied, 1.96788 s, 66.6 MB/s

Blocksize: 512k
131072000 bytes (131 MB) copied, 2.42342 s, 54.1 MB/s

Blocksize: 1024k
131072000 bytes (131 MB) copied, 1.6651 s, 78.7 MB/s


With 3.5-pre and write-back patches:

Blocksize: 4k
131072000 bytes (131 MB) copied, 5.50489 s, 23.8 MB/s

Blocksize: 8k
131072000 bytes (131 MB) copied, 1.43694 s, 91.2 MB/s

Blocksize: 16k
131072000 bytes (131 MB) copied, 0.967118 s, 136 MB/s

Blocksize: 32k
131072000 bytes (131 MB) copied, 0.707767 s, 185 MB/s

Blocksize: 64k
131072000 bytes (131 MB) copied, 0.605011 s, 217 MB/s

Blocksize: 96k
131072000 bytes (131 MB) copied, 0.573445 s, 229 MB/s

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

Blocksize: 256k
131072000 bytes (131 MB) copied, 0.458335 s, 286 MB/s

Blocksize: 512k
131072000 bytes (131 MB) copied, 0.452351 s, 290 MB/s

Blocksize: 1024k
131072000 bytes (131 MB) copied, 0.446027 s, 294 MB/s



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?


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

  parent reply	other threads:[~2012-07-05 13:07 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-03 15:53 [PATCH 0/10] fuse: An attempt to implement a write-back cache policy Pavel Emelyanov
2012-07-03 15:53 ` [PATCH 1/10] fuse: Linking file to inode helper Pavel Emelyanov
2012-07-03 15:54 ` [PATCH 2/10] fuse: Getting file for writeback helper Pavel Emelyanov
2012-07-03 15:54 ` [PATCH 3/10] fuse: Prepare to handle short reads Pavel Emelyanov
2012-07-03 15:55 ` [PATCH 4/10] fuse: Prepare to handle multiple pages in writeback Pavel Emelyanov
2012-07-04 13:06   ` Miklos Szeredi
2012-07-04 14:26     ` Pavel Emelyanov
     [not found] ` <4FF3156E.8030109-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-03 15:55   ` [PATCH 5/10] fuse: Connection bit for enabling writeback Pavel Emelyanov
2012-07-03 15:56   ` [PATCH 7/10] fuse: Flush files on wb close Pavel Emelyanov
2012-07-03 15:56   ` [PATCH 8/10] fuse: Implement writepages and write_begin/write_end callbacks Pavel Emelyanov
2012-07-03 15:57   ` [PATCH 9/10] fuse: Turn writeback on Pavel Emelyanov
2012-07-04  3:01   ` [PATCH 0/10] fuse: An attempt to implement a write-back cache policy Nikolaus Rath
     [not found]     ` <87a9zg1b7q.fsf-sKB8Sp2ER+yL2G7IJ6k9tw@public.gmane.org>
2012-07-04  7:11       ` Pavel Emelyanov
2012-07-04 13:22         ` Nikolaus Rath
     [not found]           ` <4FF4438B.8050807-BTH8mxji4b0@public.gmane.org>
2012-07-04 14:33             ` Pavel Emelyanov
     [not found]               ` <4FF45447.5000705-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-04 17:08                 ` Nikolaus Rath
2012-07-05  9:01                   ` Pavel Emelyanov
2012-07-05 13:07         ` Nikolaus Rath [this message]
2012-07-05 14:08           ` Pavel Emelyanov
2012-07-05 14:29             ` Nikolaus Rath
2012-07-05 14:34               ` Pavel Emelyanov
2012-07-06  2:04                 ` Nikolaus Rath
     [not found]                   ` <8762a1odbf.fsf-sKB8Sp2ER+yL2G7IJ6k9tw@public.gmane.org>
2012-07-06  8:46                     ` Pavel Emelyanov
2012-07-05 19:31   ` Anand Avati
     [not found]     ` <4FF5EB85.1050701-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-07-05 20:07       ` Pavel Emelyanov
2012-07-06 11:52         ` [fuse-devel] " Kirill Korotaev
2012-07-03 15:55 ` [PATCH 6/10] fuse: Trust kernel i_size only Pavel Emelyanov
2012-07-04 14:39   ` Miklos Szeredi
2012-07-05 14:10     ` Pavel Emelyanov
2012-07-10  5:53     ` Pavel Emelyanov
2012-07-13 16:30       ` Miklos Szeredi
2012-07-16  3:32         ` Pavel Emelyanov
2012-07-17 15:17           ` Miklos Szeredi
     [not found]     ` <8762a3pp3m.fsf-d8RdFUjzFsbxNFs70CDYszOMxtEWgIxa@public.gmane.org>
2012-10-01 17:30       ` Maxim V. Patlasov
2012-11-16  9:49         ` Miklos Szeredi
2012-11-16 10:32           ` Maxim V. Patlasov
2012-07-03 15:57 ` [PATCH 10/10] mm: Account for WRITEBACK_TEMP in balance_dirty_pages Pavel Emelyanov
     [not found]   ` <4FF3166B.5090800-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-13 16:57     ` Miklos Szeredi
2012-07-16  3:27       ` Pavel Emelyanov
2012-07-17 19:11         ` Miklos Szeredi
2012-07-27  4:01           ` Pavel Emelyanov
     [not found]             ` <5012127C.8070203-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-08-07 17:30               ` Miklos Szeredi
2012-07-05 19:26 ` [fuse-devel] [PATCH 0/10] fuse: An attempt to implement a write-back cache policy Anand Avati

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FF59174.1070102@rath.org \
    --to=nikolaus@rath.org \
    --cc=public-fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@plane.gmane.org \
    --cc=public-linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@plane.gmane.org \
    --cc=xemul@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).