All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Hirokazu Takahashi <taka@valinux.co.jp>
Cc: linux-kernel@vger.kernel.org, janetmor@us.ibm.com
Subject: Re: [patch] readv/writev rework
Date: Thu, 12 Sep 2002 11:47:21 -0700	[thread overview]
Message-ID: <3D80E139.ACC1719D@digeo.com> (raw)
In-Reply-To: 20020912.220041.82105437.taka@valinux.co.jp

Hirokazu Takahashi wrote:
> 
> Hello,
> 
> Your readv/writev patch interested me and I checked it.
> I found we also have a chance to improve normal writev.
> 
> a_ops->prepare_write() and a_ops->commit_write will have a
> penalty when I/O size isn't PAGE_SIZE.
> With following patch generic_file_write_nolock() will try to
> make each I/O size become PAGE_SIZE.
> 

Certainly makes a lot of sense.  If an application has a large
number of small objects which are to be appended to a file, and
they are not contiguous in user memory then this patch makes
writev() a very attractive way of doing that.  Tons faster.

However I'd be a little concerned over the increased work which a boring
old write() has to do.  Perhaps we could add a special code path
for it:

	struct iovstate {
		unsigned rest;
		unsigned copy;
		unsigned off;
		struct iovec    *work_iov;
		char            *work_buf;
		unsigned         work_iov_bytes;
	} iovstate;

	if (nr_segs != 1) {
		initialise iovstate;
	}

	...

	if (nr_segs == 1)
		page_fault = filemap_copy_from_user(page, offset, buf, bytes);
	else
		page_fault = iov_copy_from_user(&arg1, &arg2, &bytes, &iovstate);
	status = a_ops->commit_write(file, page, offset, offset+bytes);


then we can do all that fancy stuff in iov_copy_from_user().  That
function should be inlined so we don't really pass all those arguments
around.  That's just a cleanliness thing, and branching around the complex
code in the simple case.  We should be able to get the impact on the
common case down to a single taken branch per page.

  reply	other threads:[~2002-09-12 18:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-11  8:30 [patch] readv/writev rework Andrew Morton
2002-09-12 13:00 ` Hirokazu Takahashi
2002-09-12 18:47   ` Andrew Morton [this message]
2002-09-13  1:18     ` Hirokazu Takahashi
2002-09-13  3:31       ` Andrew Morton
2002-09-14  4:54         ` Andrew Morton
2002-09-14  7:39           ` Hirokazu Takahashi
2002-09-13  7:22     ` Hirokazu Takahashi
2002-09-13  8:29       ` Andrew Morton
2002-09-13  8:26         ` Hirokazu Takahashi
2002-09-13  9:23         ` Hirokazu Takahashi
2002-09-13 17:43           ` Andrew Morton

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=3D80E139.ACC1719D@digeo.com \
    --to=akpm@digeo.com \
    --cc=janetmor@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=taka@valinux.co.jp \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.