batched write

batched write

[Vladimir V. Saveliev]

Hello

On Thu, 2006-06-08 at 13:10 +0100, Christoph Hellwig wrote:
> On Thu, Jun 08, 2006 at 03:26:40PM +0400, Vladimir V. Saveliev wrote:
> > > > It may go to the kernel as a 64MB write, but VFS sends it to the FS as
> > > > 64MB/4k separate 4k writes.
> > > 
> > > Nonsense, 
> > 
> > Hans refers to generic_file_write which does
> > prepare_write
> > copy_from_user
> > commit_write
> > for each page.
> 
> That's not really the vfs but the generic pagecache routines.  For some
> filesystems (e.g. XFS) only reservations for delayed allocations are
> performed in this path so it doesn't really matter.  For not so advanced
> filesystems batching these calls would definitly be very helpful.  Patches
> to get there are very welcome.
> 

The core of generic_file_buffered_write is 
do {
	grab_cache_page();
	a_ops->prepare_write();
	copy_from_user();
	a_ops->commit_write();
	
	filemap_set_next_iovec();
	balance_dirty_pages_ratelimited();
} while (count);


Would it make sence to rework this code with adding new address_space
operation - fill_pages so that looks like:

do {
	a_ops->fill_pages();
	filemap_set_next_iovec();
	balance_dirty_pages_ratelimited();
} while (count);

generic implementation of fill_pages would look like:

generic_fill_pages()
{
	grab_cache_page();
	a_ops->prepare_write();
	copy_from_user();
	a_ops->commit_write();
}

I believe that filesystem developers will want to exploit that
operation. 

Any opinion on this plan is welcomed. I would try to code whatever we
will have developed (I hope) in result of this discussion.

Re: batched write

[Andrew Morton]

On Thu, 15 Jun 2006 02:08:32 +0400
"Vladimir V. Saveliev" <vs@namesys.com> wrote:

> The core of generic_file_buffered_write is 
> do {
> 	grab_cache_page();
> 	a_ops->prepare_write();
> 	copy_from_user();
> 	a_ops->commit_write();
> 	
> 	filemap_set_next_iovec();
> 	balance_dirty_pages_ratelimited();
> } while (count);
> 
> 
> Would it make sence to rework this code with adding new address_space
> operation - fill_pages so that looks like:
> 
> do {
> 	a_ops->fill_pages();
> 	filemap_set_next_iovec();
> 	balance_dirty_pages_ratelimited();
> } while (count);
> 
> generic implementation of fill_pages would look like:
> 
> generic_fill_pages()
> {
> 	grab_cache_page();
> 	a_ops->prepare_write();
> 	copy_from_user();
> 	a_ops->commit_write();
> }
> 

There's nothing which leaps out and says "wrong" in this.  But there's
nothing which leaps out and says "right", either.  It seems somewhat
arbitrary, that's all.

We have one filesystem which wants such a refactoring (although I don't
think you've adequately spelled out _why_ reiser4 wants this).

To be able to say "yes, we want this" I think we'd need to understand which
other filesystems would benefit from exploiting it, and with what results?

Re: batched write

[Hans Reiser]

Andrew Morton wrote:

>We have one filesystem which wants such a refactoring (although I don't
>think you've adequately spelled out _why_ reiser4 wants this).
>  
>
>
When calling the filesystem for writes, there is processing that must be
done:

1) per word

2) per page

3) per call to the FS

If the FS is called per page, then it turns out that 3) costs more than
1) and 2) for sophisticated filesystems.  As we develop fancier and
fancier plugins this will just get more and more true.  It decreases CPU
usage by 2x to use per sys_write calls into reiser4 rather than per page
calls into reiser4.  (Vladimir, on Monday can you find and send your
benchmarks?)  This is significant for cached writes.

If it violates the intuition to believe this, then let me point out that
there was a similar motivation for the creation of bios: calling the
block layer traverses more lines of code than copying a page of bytes
does.  Unfortunately, all that code turns out to be useful
optimizations, so one cannot just take the attitude (whether for the
block layer or reiser4) that it should just be simplified.

Please note that I have no real problem with leaving the generic code
unchanged and having reiser4 do its own write operation.  I am modifying
the generic code because you suggested it was preferred.  Having
reviewed the code in detail, I see that you were right and it is better
to just fix the generic code to call more than 4k at a time into the FS,
and then be able to reuse the generic aio and direct io code (and etc.)
as a result.  So, to be sociable, and to get more code reuse, we make
this proposal.

>To be able to say "yes, we want this" I think we'd need to understand which
>other filesystems would benefit from exploiting it, and with what results?
>
>
>  
>
Or just let us have our own sys_write implementation without being
excluded for it.  I have shown that it is significantly faster for
reiser4 to process things more than 4k at a time.

Re: batched write

[Nix]

On 17 Jun 2006, Hans Reiser prattled cheerily:
> If the FS is called per page, then it turns out that 3) costs more than
> 1) and 2) for sophisticated filesystems.  As we develop fancier and
> fancier plugins this will just get more and more true.  It decreases CPU
> usage by 2x to use per sys_write calls into reiser4 rather than per page
> calls into reiser4.

This seems to me to be something that FUSE filesystems might well like,
too: I know one I'm working on would like to know the real size of the
original write request (so that it can optimize layout appropriately
for things frequently written in large chunks; the assumption being that
if it's written in large chunks it's likely to be read in large chunks
too).

-- 
`Voting for any American political party is fundamentally
 incomprehensible.' --- Vadik

Re: batched write

[Hans Reiser]

Nix wrote:

>On 17 Jun 2006, Hans Reiser prattled cheerily:
>  
>
>>If the FS is called per page, then it turns out that 3) costs more than
>>1) and 2) for sophisticated filesystems.  As we develop fancier and
>>fancier plugins this will just get more and more true.  It decreases CPU
>>usage by 2x to use per sys_write calls into reiser4 rather than per page
>>calls into reiser4.
>>    
>>
>
>This seems to me to be something that FUSE filesystems might well like,
>too: I know one I'm working on would like to know the real size of the
>original write request (so that it can optimize layout appropriately
>for things frequently written in large chunks; the assumption being that
>if it's written in large chunks it's likely to be read in large chunks
>too).
>
>  
>
Hi Nix,

Forgive myn utter ignorance of fuse, but does it currently context
switch to user space for every 4k written through VFS?

Re: batched write

[Miklos Szeredi]

> 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

Re: batched write

[Hans Reiser]

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.

Re: batched write

[Miklos Szeredi]

> I would think that batched write is pretty essential then to FUSE
> performance.

Well, yes essential if the this is the bottleneck in write throughput,
which is most often not the case, but sometimes it is.

Miklos

Re: batched write

[Akshat Aranya]

On 6/19/06, Miklos Szeredi <miklos@szeredi.hu> wrote:
> > I would think that batched write is pretty essential then to FUSE
> > performance.
>
> Well, yes essential if the this is the bottleneck in write throughput,
> which is most often not the case, but sometimes it is.
>

I can vouch for this.  I did some experiments with an example FUSE
filesystem that discards the data in userspace.  Exporting such a
filesystem over NFS gives us 80 MB/s writes when FUSE is modified to
write with 32K block sizes.  With the standard FUSE (4K writes), we
get  closer to 50 MB/s.

> Miklos


-Akshat
> 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
>

Re: batched write

[Hans Reiser]

Akshat Aranya wrote:

> On 6/19/06, Miklos Szeredi <miklos@szeredi.hu> wrote:
>
>> > I would think that batched write is pretty essential then to FUSE
>> > performance.
>>
>> Well, yes essential if the this is the bottleneck in write throughput,
>> which is most often not the case, but sometimes it is.
>>
>
> I can vouch for this.  I did some experiments with an example FUSE
> filesystem that discards the data in userspace.  Exporting such a
> filesystem over NFS gives us 80 MB/s writes when FUSE is modified to
> write with 32K block sizes.  With the standard FUSE (4K writes), we
> get  closer to 50 MB/s.

The ratios of 4k performance / large write performance are amusingly
similar for reiser4 and FUSE even though the filesystems and absolute
performance are totally different.  The principle is the same it seems
for both filesystems.

Vladimir, the benchmarks, please send them.....

Hans

Re: batched write

[Andreas Dilger]

On Jun 17, 2006  10:04 -0700, Andrew Morton wrote:
> On Thu, 15 Jun 2006 02:08:32 +0400
> "Vladimir V. Saveliev" <vs@namesys.com> wrote:
> 
> > The core of generic_file_buffered_write is 
> > do {
> > 	grab_cache_page();
> > 	a_ops->prepare_write();
> > 	copy_from_user();
> > 	a_ops->commit_write();
> > 	
> > 	filemap_set_next_iovec();
> > 	balance_dirty_pages_ratelimited();
> > } while (count);
> > 
> > 
> > Would it make sence to rework this code with adding new address_space
> > operation - fill_pages so that looks like:
> > 
> > do {
> > 	a_ops->fill_pages();
> > 	filemap_set_next_iovec();
> > 	balance_dirty_pages_ratelimited();
> > } while (count);
> > 
> > generic implementation of fill_pages would look like:
> > 
> > generic_fill_pages()
> > {
> > 	grab_cache_page();
> > 	a_ops->prepare_write();
> > 	copy_from_user();
> > 	a_ops->commit_write();
> > }
> > 
> 
> There's nothing which leaps out and says "wrong" in this.  But there's
> nothing which leaps out and says "right", either.  It seems somewhat
> arbitrary, that's all.
> 
> We have one filesystem which wants such a refactoring (although I don't
> think you've adequately spelled out _why_ reiser4 wants this).
> 
> To be able to say "yes, we want this" I think we'd need to understand which
> other filesystems would benefit from exploiting it, and with what results?

With the caveat that I didn't see the original patch, if this can be a step
down the road toward supporting delayed allocation at the VFS level then
I'm all for such changes.

Lustre goes to some lengths to batch up reads and writes on the client into
large (1MB+) RPCs in order to maximize performance.  Similarly on the
server we essentially bypass the VFS in order to allocate all of the RPC's
blocks in one call and do a large bio write in a second.  It just isn't
possible to maximize performance if everything is split into PAGE_SIZE
chunks.

I believe XFS would benefit from delayed allocation, and the ext3-delalloc
patches from Alex also provide a large part of the performance wins for
userspace IO, when they allow large sys_write() and VM cache flush to
efficiently call into the filesystem to allocate many blocks at once, and
then push them out to disk in large chunks.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

Re: batched write

[Hans Reiser]

Andreas Dilger wrote:

>On Jun 17, 2006  10:04 -0700, Andrew Morton wrote:
>  
>
>>On Thu, 15 Jun 2006 02:08:32 +0400
>>"Vladimir V. Saveliev" <vs@namesys.com> wrote:
>>
>>    
>>
>>>The core of generic_file_buffered_write is 
>>>do {
>>>	grab_cache_page();
>>>	a_ops->prepare_write();
>>>	copy_from_user();
>>>	a_ops->commit_write();
>>>	
>>>	filemap_set_next_iovec();
>>>	balance_dirty_pages_ratelimited();
>>>} while (count);
>>>
>>>
>>>Would it make sence to rework this code with adding new address_space
>>>operation - fill_pages so that looks like:
>>>
>>>do {
>>>	a_ops->fill_pages();
>>>	filemap_set_next_iovec();
>>>	balance_dirty_pages_ratelimited();
>>>} while (count);
>>>
>>>generic implementation of fill_pages would look like:
>>>
>>>generic_fill_pages()
>>>{
>>>	grab_cache_page();
>>>	a_ops->prepare_write();
>>>	copy_from_user();
>>>	a_ops->commit_write();
>>>}
>>>
>>>      
>>>
>>There's nothing which leaps out and says "wrong" in this.  But there's
>>nothing which leaps out and says "right", either.  It seems somewhat
>>arbitrary, that's all.
>>
>>We have one filesystem which wants such a refactoring (although I don't
>>think you've adequately spelled out _why_ reiser4 wants this).
>>
>>To be able to say "yes, we want this" I think we'd need to understand which
>>other filesystems would benefit from exploiting it, and with what results?
>>    
>>
>
>With the caveat that I didn't see the original patch, if this can be a step
>down the road toward supporting delayed allocation at the VFS level then
>I'm all for such changes.
>  
>
What do you mean by supporting delayed allocation at the VFS level?  Do
you mean calling to the FS or maybe just not stepping on the FS's toes
so much or?  Delayed allocation is very fs specific in so far as I can
imagine it.

>Lustre goes to some lengths to batch up reads and writes on the client into
>large (1MB+) RPCs in order to maximize performance.  Similarly on the
>server we essentially bypass the VFS in order to allocate all of the RPC's
>blocks in one call and do a large bio write in a second.  It just isn't
>possible to maximize performance if everything is split into PAGE_SIZE
>chunks.
>
>I believe XFS would benefit from delayed allocation, and the ext3-delalloc
>patches from Alex also provide a large part of the performance wins for
>userspace IO, when they allow large sys_write() and VM cache flush to
>efficiently call into the filesystem to allocate many blocks at once, and
>then push them out to disk in large chunks.
>
>Cheers, Andreas
>--
>Andreas Dilger
>Principal Software Engineer
>Cluster File Systems, Inc.
>
>
>
>  
>

Re: batched write

[Andreas Dilger]

On Jun 19, 2006  09:51 -0700, Hans Reiser wrote:
> Andreas Dilger wrote:
> >With the caveat that I didn't see the original patch, if this can be a step
> >down the road toward supporting delayed allocation at the VFS level then
> >I'm all for such changes.
>
> What do you mean by supporting delayed allocation at the VFS level?  Do
> you mean calling to the FS or maybe just not stepping on the FS's toes
> so much or?  Delayed allocation is very fs specific in so far as I can
> imagine it.

Currently the VM/VFS call into the filesystem in ->prepare_write for each
page to do block allocation for the filesystem.  This is the filesystem's
chance to return -ENOSPC, etc, because after that point the dirty pages
are written asynchronously and there is no guarantee that the application
will even be around when they are finally written to disk.

If the VFS supported delayed allocation it would call into the filesystem
on a per-sys_write basis to allow the filesystem to RESERVE space for all
of the pages in the write call, and then later (under memory pressure,
page aging, or even "pull" from the fs) submit a whole batch of contiguous
pages to the fs efficiently (via ->fill_pages() or whatever).

The fs can know at that time the final file size (if the file isn't still
being dirtied), can allocate all these blocks in a contiguous chunk, can
submit all of the IO in a single bio to the block layer or RPC/RDMA to net.

As you well know, while it is possible to do this now by copying all of the
generic_file_write() logic into the filesystem *_file_write() method, in
practise it is hard to do this from a code maintenance point of view.


Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

Re: batched write

[Hans Reiser]

Andreas Dilger wrote:

>
>If the VFS supported delayed allocation it would call into the filesystem
>on a per-sys_write basis 
>
Is it necessary for VFS to specify that it is for delayed allocation
that it does it, or can it be a more generic sort of per sys-write call?

>to allow the filesystem to RESERVE space for all
>of the pages in the write call, and then later (under memory pressure,
>page aging, or even "pull" from the fs) submit a whole batch of contiguous
>pages to the fs efficiently (via ->fill_pages() or whatever).
>  
>

Re: batched write

[David Chinner]

On Mon, Jun 19, 2006 at 12:50:49PM -0600, Andreas Dilger wrote:
> On Jun 19, 2006  09:51 -0700, Hans Reiser wrote:
> > Andreas Dilger wrote:
> > >With the caveat that I didn't see the original patch, if this can be a step
> > >down the road toward supporting delayed allocation at the VFS level then
> > >I'm all for such changes.
> >
> > What do you mean by supporting delayed allocation at the VFS level?  Do
> > you mean calling to the FS or maybe just not stepping on the FS's toes
> > so much or?  Delayed allocation is very fs specific in so far as I can
> > imagine it.
> 
> Currently the VM/VFS call into the filesystem in ->prepare_write for each
> page to do block allocation for the filesystem.  This is the filesystem's
> chance to return -ENOSPC, etc, because after that point the dirty pages
> are written asynchronously and there is no guarantee that the application
> will even be around when they are finally written to disk.
> 
> If the VFS supported delayed allocation it would call into the filesystem
> on a per-sys_write basis to allow the filesystem to RESERVE space for all
> of the pages in the write call,

The VFS doesn't need to support delalloc as delalloc is fundamentally a
filesystem property. The VFS it already provides a hook for delalloc space
reservation that can return ENOSPC - it's called ->prepare_write().

Sure, a batch interface would be nice, but that's an optimisation that
needs to be done regardless of whether the filesystem supports delalloc or
not.  The current ->prepare_write() interface shows its limits when having to
do hundreds of thousands (millions, even) of ->prepare_write() calls per
second. This makes for entertaining scaling problems that batching would
make less of a problem.

> and then later (under memory pressure,
> page aging, or even "pull" from the fs) submit a whole batch of contiguous
> pages to the fs efficiently (via ->fill_pages() or whatever).

Can be done right now - XFS does this probe-and-pull operation already for
writes. See xfs_probe_cluster(), xfs_cluster_write() and friends.

Yes, it would be nice to have the VM pass us clusters of adjacent pages, but
given that the file layout drives the cluster size it is more appropriate
to do this from the filesystem. Also, the pages do not contain the state
necessary for the VM to cluster pages in an way that results in efficient
I/O patterns.

Basically, the only thing really needed from the VFS/VM is a method of tagging
delalloc (or unwritten) pages so that the writepage path knows how to treat
the page being written. Currently we keep that state in bufferheads (e.g. see
buffer_delay() usage) attached to the page......

> The fs can know at that time the final file size (if the file isn't still
> being dirtied), can allocate all these blocks in a contiguous chunk, can
> submit all of the IO in a single bio to the block layer or RPC/RDMA to net.

You don't need to know the final file size - just what is contiguous in the
page cache and in the same state as the page being flushed.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: batched write

[Hans Reiser]

So far we have XFS, FUSE, and reiser4 benefiting from the potential
ability to process more than 4k at a time.  Is it enough?

Re: batched write

[Andrew Morton]

On Tue, 20 Jun 2006 00:19:24 -0700
Hans Reiser <reiser@namesys.com> wrote:

> So far we have XFS, FUSE, and reiser4 benefiting from the potential
> ability to process more than 4k at a time.  Is it enough?

Spose so.  Let's see what the diff looks like?

Re: batched write

[Steven Whitehouse]

Hi,

On Tue, 2006-06-20 at 00:26 -0700, Andrew Morton wrote:
> On Tue, 20 Jun 2006 00:19:24 -0700
> Hans Reiser <reiser@namesys.com> wrote:
> 
> > So far we have XFS, FUSE, and reiser4 benefiting from the potential
> > ability to process more than 4k at a time.  Is it enough?
> 
> Spose so.  Let's see what the diff looks like?
> -

I have plans to do something along these lines for GFS2 in the future,
so you can add that to the list as well, if that helps things along,

Steve.

Re: batched write

[Vladimir V. Saveliev]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

Hello

On Tue, 2006-06-20 at 00:26 -0700, Andrew Morton wrote:
> On Tue, 20 Jun 2006 00:19:24 -0700
> Hans Reiser <reiser@namesys.com> wrote:
> 
> > So far we have XFS, FUSE, and reiser4 benefiting from the potential
> > ability to process more than 4k at a time.  Is it enough?
> 
> Spose so.  Let's see what the diff looks like?
> 
ok, the first draft version for evaluation is here.

[-- Attachment #2: batched-write.patch --]
[-- Type: text/x-patch, Size: 8721 bytes --]


This patch adds a method fill_pages to struct address_space_operations.
A filesystem may want to implement this operation to improve write performance.
Generic implementation for the method is made by cut-n-paste off generic_file_buffered_write:
it writes one page using prepare_write and commit_write address space operations.

NOTE: just for evaluation, compiliable only yet. 



diff -puN mm/filemap.c~batched-write mm/filemap.c
--- linux-2.6.17-rc6-mm2/mm/filemap.c~batched-write	2006-06-12 16:06:43.000000000 +0400
+++ linux-2.6.17-rc6-mm2-vs/mm/filemap.c	2006-06-20 19:52:53.000000000 +0400
@@ -2093,68 +2093,78 @@ generic_file_direct_write(struct kiocb *
 }
 EXPORT_SYMBOL(generic_file_direct_write);
 
-ssize_t
-generic_file_buffered_write(struct kiocb *iocb, const struct iovec *iov,
-		unsigned long nr_segs, loff_t pos, loff_t *ppos,
-		size_t count, ssize_t written)
+typedef size_t (*write_actor_t)(struct page *, unsigned long, size_t,
+				const write_descriptor_t *);
+struct write_descriptor {
+	loff_t pos;
+	size_t count;
+	const struct iovec *cur_iov;	/* current iovec */
+	size_t iov_base;		/* offset in the current iovec */
+	char __user *buf;
+	write_actor_t actor;
+};
+
+static size_t write_actor(struct page *page, unsigned long offset, size_t bytes,
+			  const write_descriptor_t *desc)
 {
-	struct file *file = iocb->ki_filp;
-	struct address_space * mapping = file->f_mapping;
-	const struct address_space_operations *a_ops = mapping->a_ops;
-	struct inode 	*inode = mapping->host;
-	long		status = 0;
-	struct page	*page;
-	struct page	*cached_page = NULL;
-	size_t		bytes;
-	struct pagevec	lru_pvec;
-	const struct iovec *cur_iov = iov; /* current iovec */
-	size_t		iov_base = 0;	   /* offset in the current iovec */
-	char __user	*buf;
+	return filemap_copy_from_user(page, offset, desc->buf, bytes);
+}
 
-	pagevec_init(&lru_pvec, 0);
+static size_t write_iovec_actor(struct page *page, unsigned long offset,
+				size_t bytes, const write_descriptor_t *desc)
+{
+	return filemap_copy_from_user_iovec(page, offset, desc->cur_iov,
+					    desc->iov_base, bytes);
+}
+
+/**
+ * generic_fill_pages
+ * @file:
+ * @desc:
+ * @lru_pvec:
+ * @cached_page:
+ * @copied:
+ *
+ * Number of bytes written is returned via @copied.
+ */
+long generic_fill_pages(struct file *file, const write_descriptor_t *desc,
+			struct pagevec *lru_pvec, struct page **cached_page,
+			size_t *copied)
+{
+	const struct address_space_operations *a_ops = file->f_mapping->a_ops;
+	struct page *page;
+	unsigned long index;
+	size_t bytes;
+	unsigned long offset;
+	unsigned long maxlen;
+	long status;
+
+	offset = (desc->pos & (PAGE_CACHE_SIZE - 1)); /* Within page */
+	index = desc->pos >> PAGE_CACHE_SHIFT;
+	bytes = PAGE_CACHE_SIZE - offset;
+	if (bytes > desc->count)
+		bytes = desc->count;
 
 	/*
-	 * handle partial DIO write.  Adjust cur_iov if needed.
+	 * Bring in the user page that we will copy from _first_.
+	 * Otherwise there's a nasty deadlock on copying from the same
+	 * page as we're writing to, without it being marked
+	 * up-to-date.
 	 */
-	if (likely(nr_segs == 1))
-		buf = iov->iov_base + written;
-	else {
-		filemap_set_next_iovec(&cur_iov, &iov_base, written);
-		buf = cur_iov->iov_base + iov_base;
-	}
-
-	do {
-		unsigned long index;
-		unsigned long offset;
-		unsigned long maxlen;
-		size_t copied;
-
-		offset = (pos & (PAGE_CACHE_SIZE -1)); /* Within page */
-		index = pos >> PAGE_CACHE_SHIFT;
-		bytes = PAGE_CACHE_SIZE - offset;
-		if (bytes > count)
-			bytes = count;
-
-		/*
-		 * Bring in the user page that we will copy from _first_.
-		 * Otherwise there's a nasty deadlock on copying from the
-		 * same page as we're writing to, without it being marked
-		 * up-to-date.
-		 */
-		maxlen = cur_iov->iov_len - iov_base;
-		if (maxlen > bytes)
-			maxlen = bytes;
-		fault_in_pages_readable(buf, maxlen);
-
-		page = __grab_cache_page(mapping,index,&cached_page,&lru_pvec);
-		if (!page) {
-			status = -ENOMEM;
-			break;
-		}
+	maxlen = desc->cur_iov->iov_len - desc->iov_base;
+	if (maxlen > bytes)
+		maxlen = bytes;
+
+	while (1) {
+		fault_in_pages_readable(desc->buf, maxlen);
+
+		page = __grab_cache_page(file->f_mapping, index, cached_page, lru_pvec);
+		if (!page)
+			return -ENOMEM;
 
 		status = a_ops->prepare_write(file, page, offset, offset+bytes);
 		if (unlikely(status)) {
-			loff_t isize = i_size_read(inode);
+			loff_t isize = i_size_read(file->f_mapping->host);
 
 			if (status != AOP_TRUNCATED_PAGE)
 				unlock_page(page);
@@ -2162,51 +2172,87 @@ generic_file_buffered_write(struct kiocb
 			if (status == AOP_TRUNCATED_PAGE)
 				continue;
 			/*
-			 * prepare_write() may have instantiated a few blocks
-			 * outside i_size.  Trim these off again.
+			 * prepare_write() may have instantiated a few
+			 * blocks outside i_size.  Trim these off
+			 * again.
 			 */
-			if (pos + bytes > isize)
-				vmtruncate(inode, isize);
-			break;
+			if (desc->pos + bytes > isize)
+				vmtruncate(file->f_mapping->host, isize);
+			return status;
 		}
-		if (likely(nr_segs == 1))
-			copied = filemap_copy_from_user(page, offset,
-							buf, bytes);
-		else
-			copied = filemap_copy_from_user_iovec(page, offset,
-						cur_iov, iov_base, bytes);
+
+		*copied = desc->actor(page, offset, bytes, desc);
+
 		flush_dcache_page(page);
 		status = a_ops->commit_write(file, page, offset, offset+bytes);
 		if (status == AOP_TRUNCATED_PAGE) {
 			page_cache_release(page);
 			continue;
 		}
-		if (likely(copied > 0)) {
-			if (!status)
-				status = copied;
 
-			if (status >= 0) {
-				written += status;
-				count -= status;
-				pos += status;
-				buf += status;
-				if (unlikely(nr_segs > 1)) {
-					filemap_set_next_iovec(&cur_iov,
-							&iov_base, status);
-					if (count)
-						buf = cur_iov->iov_base +
-							iov_base;
-				} else {
-					iov_base += status;
-				}
-			}
-		}
-		if (unlikely(copied != bytes))
-			if (status >= 0)
-				status = -EFAULT;
 		unlock_page(page);
 		mark_page_accessed(page);
 		page_cache_release(page);
+		break;
+	}
+	if (status)
+		*copied = 0;
+	else if (*copied != bytes)
+		status = -EFAULT;
+	return status;
+}
+
+ssize_t
+generic_file_buffered_write(struct kiocb *iocb, const struct iovec *iov,
+			    unsigned long nr_segs, loff_t pos, loff_t *ppos,
+			    size_t count, ssize_t written)
+{
+	struct file *file = iocb->ki_filp;
+	struct address_space * mapping = file->f_mapping;
+	const struct address_space_operations *a_ops = mapping->a_ops;
+	struct inode 	*inode = mapping->host;
+	long		status;
+	struct page	*cached_page = NULL;
+	struct pagevec	lru_pvec;
+	write_descriptor_t desc;
+	size_t copied = 0;
+
+	pagevec_init(&lru_pvec, 0);
+
+	desc.pos = pos;
+	desc.count = count;
+	desc.cur_iov = iov;
+	desc.iov_base = 0;
+
+	/*
+	 * handle partial DIO write.  Adjust cur_iov if needed.
+	 */
+	if (likely(nr_segs == 1)) {
+		desc.buf = iov->iov_base + written;
+		desc.actor = write_actor;
+	} else {
+		filemap_set_next_iovec(&desc.cur_iov, &desc.iov_base, written);
+		desc.buf = desc.cur_iov->iov_base + desc.iov_base;
+		desc.actor = write_iovec_actor;
+	}
+
+	do {
+		status = mapping->a_ops->fill_pages(file, &desc,
+						    &lru_pvec, &cached_page, &copied);
+		if (likely(copied > 0)) {
+			written += copied;
+			desc.count -= copied;
+			desc.pos += copied;
+			desc.buf += copied;
+			if (unlikely(nr_segs > 1)) {
+				filemap_set_next_iovec(&desc.cur_iov,
+						       &desc.iov_base, copied);
+				if (count)
+					desc.buf = desc.cur_iov->iov_base + desc.iov_base;
+			} else {
+				desc.iov_base += copied;
+			}
+		}
 		if (status < 0)
 			break;
 		balance_dirty_pages_ratelimited(mapping);
diff -puN include/linux/fs.h~batched-write include/linux/fs.h
--- linux-2.6.17-rc6-mm2/include/linux/fs.h~batched-write	2006-06-16 19:12:47.000000000 +0400
+++ linux-2.6.17-rc6-mm2-vs/include/linux/fs.h	2006-06-20 19:40:26.000000000 +0400
@@ -346,6 +346,9 @@ enum positive_aop_returns {
 struct page;
 struct address_space;
 struct writeback_control;
+typedef struct write_descriptor write_descriptor_t;
+
+#include <linux/pagevec.h>
 
 struct address_space_operations {
 	int (*writepage)(struct page *page, struct writeback_control *wbc);
@@ -367,6 +370,9 @@ struct address_space_operations {
 	 */
 	int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
 	int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
+	long (*fill_pages)(struct file *, const write_descriptor_t *,
+			   struct pagevec *, struct page **, size_t *copied);
+
 	/* Unfortunately this kludge is needed for FIBMAP. Don't use it */
 	sector_t (*bmap)(struct address_space *, sector_t);
 	void (*invalidatepage) (struct page *, unsigned long);

_

Re: batched write

[Hans Reiser]

Hold off on reading this, there will be a tested version with comments,
etc., later this week.  

Re: batched write

[Vladimir V. Saveliev]

Hello

On Mon, 2006-06-19 at 09:27 -0700, Andreas Dilger wrote:
> On Jun 17, 2006  10:04 -0700, Andrew Morton wrote:
> > On Thu, 15 Jun 2006 02:08:32 +0400
> > "Vladimir V. Saveliev" <vs@namesys.com> wrote:
> > 
> > > The core of generic_file_buffered_write is 
> > > do {
> > > 	grab_cache_page();
> > > 	a_ops->prepare_write();
> > > 	copy_from_user();
> > > 	a_ops->commit_write();
> > > 	
> > > 	filemap_set_next_iovec();
> > > 	balance_dirty_pages_ratelimited();
> > > } while (count);
> > > 
> > > 
> > > Would it make sence to rework this code with adding new address_space
> > > operation - fill_pages so that looks like:
> > > 
> > > do {
> > > 	a_ops->fill_pages();
> > > 	filemap_set_next_iovec();
> > > 	balance_dirty_pages_ratelimited();
> > > } while (count);
> > > 
> > > generic implementation of fill_pages would look like:
> > > 
> > > generic_fill_pages()
> > > {
> > > 	grab_cache_page();
> > > 	a_ops->prepare_write();
> > > 	copy_from_user();
> > > 	a_ops->commit_write();
> > > }
> > > 
> > 
> > There's nothing which leaps out and says "wrong" in this.  But there's
> > nothing which leaps out and says "right", either.  It seems somewhat
> > arbitrary, that's all.
> > 
> > We have one filesystem which wants such a refactoring (although I don't
> > think you've adequately spelled out _why_ reiser4 wants this).
> > 
> > To be able to say "yes, we want this" I think we'd need to understand which
> > other filesystems would benefit from exploiting it, and with what results?
> 
> With the caveat that I didn't see the original patch, if this can be a step
> down the road toward supporting delayed allocation at the VFS level then
> I'm all for such changes.
> 

Doesn't writepages method operation of address space provide enough
freedom for a filesystem to perform delayed allocation?

The goal of the patch was just to allow a filesystem to perform metadata
update for several newly added to a file pages at once. Currently,
filesystem is asked to do that once per page. Filesystems which have
complex algorithms involved into that may find this possibility useful
to improve performance.

> Lustre goes to some lengths to batch up reads and writes on the client into
> large (1MB+) RPCs in order to maximize performance.  Similarly on the
> server we essentially bypass the VFS in order to allocate all of the RPC's
> blocks in one call and do a large bio write in a second.  It just isn't
> possible to maximize performance if everything is split into PAGE_SIZE
> chunks.
> 
> I believe XFS would benefit from delayed allocation, and the ext3-delalloc
> patches from Alex also provide a large part of the performance wins for
> userspace IO, when they allow large sys_write() and VM cache flush to
> efficiently call into the filesystem to allocate many blocks at once, and
> then push them out to disk in large chunks.
> 
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.
> 
>