Re: batched write

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 15 Jun 2006 02:08:32 +0400
"Vladimir V. Saveliev" <vs@xxxxxxxxxxx> 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?
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux