Messages in this thread | | | Subject | batched write | From | "Vladimir V. Saveliev" <> | Date | Thu, 15 Jun 2006 02:08:32 +0400 |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |