From: Avi Kivity <avi@argo.co.il>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Al Viro <viro@ftp.linux.org.uk>,
hch@lst.de, akpm@osdl.org, davem@redhat.com,
Ulrich Drepper <drepper@redhat.com>,
Linus Torvalds <torvalds@osdl.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] New iovec support & VFS changes
Date: Tue, 20 Dec 2005 20:00:01 +0200 [thread overview]
Message-ID: <43A846A1.4080007@argo.co.il> (raw)
In-Reply-To: <1135095487.19193.90.camel@localhost.localdomain>
Badari Pulavarty wrote:
>I was trying to add support for preadv()/pwritev() for threaded
>databases. Currently the patch is in -mm tree.
>
>http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-
>rc5/2.6.15-rc5-mm3/broken-out/support-for-preadv-pwritev.patch
>
>This needs a new set of system calls. Ulrich Drepper pointed out
>that, instead of adding a system call for the limited functionality
>it provides, why not we add new iovec interface as follows (offset-per-
>segment) which provides greater functionality & flexibility.
>
>+struct niovec
>+{
>+ void __user *iov_base;
>+ __kernel_size_t iov_len;
>+ __kernel_loff_t iov_off; /* NEW */
>+};
>
>In order to support this, we need to change all the file_operations
>(readv/writev) and its helper functions to take this new structure.
>
>I took a stab at doing it and I want feedback on whether this is
>acceptable. All the patch does - is to make kernel use new structure,
>but the existing syscalls like readv()/writev() still deals with
>original one to keep the compatibility. (pipes and sockets need
>changing too - which I have not addressed yet).
>
>Is this the right approach ?
>
>
>
You can io_submit() a list of IO_CMD_PREAD[V]s and immediately
io_getevents() them. In addition to specifying different file offsets
you can mix reads and writes, mix file descriptors, and reap nonblocking
events quickly (by specifying a timeout of zero).
Sure, it's two syscalls instead of one, but it's much more flexibles,
and databases should be using aio anyway. Oh, and no kernel changes
needed, apart from merging vectored aio.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
next prev parent reply other threads:[~2005-12-20 18:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-20 16:18 Badari Pulavarty
2005-12-20 16:59 ` Jamie Lokier
2005-12-20 17:26 ` Badari Pulavarty
2005-12-20 18:00 ` Avi Kivity [this message]
2005-12-20 18:08 ` Badari Pulavarty
2005-12-20 18:20 ` Avi Kivity
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=43A846A1.4080007@argo.co.il \
--to=avi@argo.co.il \
--cc=akpm@osdl.org \
--cc=davem@redhat.com \
--cc=drepper@redhat.com \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbadari@us.ibm.com \
--cc=torvalds@osdl.org \
--cc=viro@ftp.linux.org.uk \
/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
Powered by JetHome