linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: nix@esperi.org.uk, akpm@osdl.org, vs@namesys.com,
	hch@infradead.org, Reiserfs-Dev@namesys.com,
	Linux-Kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	drepper@redhat.com
Subject: Re: batched write
Date: Mon, 19 Jun 2006 09:39:43 -0700	[thread overview]
Message-ID: <4496D34F.4010007@namesys.com> (raw)
In-Reply-To: <E1FsHzf-0004ES-00@dorka.pomaz.szeredi.hu>

Miklos Szeredi wrote:

>>Forgive myn utter ignorance of fuse, but does it currently context
>>switch to user space for every 4k written through VFS?
>>    
>>
>
>Yes, unfortunately it does, so fuse would benefit from batched writing
>as well, with some constraint on the number of locked pages to avoid
>DoS against the page cache.
>
>Miklos
>
>
>  
>
I would think that batched write is pretty essential then to FUSE
performance.  If we could then get the glibc authors to not sabotage the
using of a large block size to indicate that we like large IOs (see
thread on fseek implementation), reiser4 and FUSE would be all set for
improved performance.  Even without glibc developer cooperation, we will
get a lot of benefits.

  reply	other threads:[~2006-06-19 16:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <44736D3E.8090808@namesys.com>
     [not found] ` <20060524175312.GA3579@zero>
     [not found]   ` <44749E24.40203@namesys.com>
     [not found]     ` <20060608110044.GA5207@suse.de>
     [not found]       ` <1149766000.6336.29.camel@tribesman.namesys.com>
     [not found]         ` <20060608121006.GA8474@infradead.org>
2006-06-14 22:08           ` batched write Vladimir V. Saveliev
2006-06-17 17:04             ` Andrew Morton
2006-06-17 17:51               ` Hans Reiser
2006-06-18 11:20                 ` Nix
2006-06-19  9:05                   ` Hans Reiser
2006-06-19 11:32                     ` Miklos Szeredi
2006-06-19 16:39                       ` Hans Reiser [this message]
2006-06-19 17:35                         ` Miklos Szeredi
2006-06-19 17:52                           ` Akshat Aranya
2006-06-19 20:39                             ` Hans Reiser
2006-06-19 16:27               ` Andreas Dilger
2006-06-19 16:51                 ` Hans Reiser
2006-06-19 18:50                   ` Andreas Dilger
2006-06-19 20:47                     ` Hans Reiser
2006-06-20  0:01                     ` David Chinner
2006-06-20  7:19                       ` Hans Reiser
2006-06-20  7:26                         ` Andrew Morton
2006-06-20  9:02                           ` Steven Whitehouse
2006-06-20 16:26                           ` Vladimir V. Saveliev
2006-06-20 17:29                             ` Hans Reiser
2006-06-19 18:28                 ` Vladimir V. Saveliev

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=4496D34F.4010007@namesys.com \
    --to=reiser@namesys.com \
    --cc=Linux-Kernel@vger.kernel.org \
    --cc=Reiserfs-Dev@namesys.com \
    --cc=akpm@osdl.org \
    --cc=drepper@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=nix@esperi.org.uk \
    --cc=vs@namesys.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).