All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zach Brown <zab@zabbo.net>
To: Benjamin LaHaise <bcrl@kvack.org>
Cc: Suparna Bhattacharya <suparna@in.ibm.com>,
	linux-aio@kvack.org, linux-kernel@vger.kernel.org,
	wli@holomorphy.com, mason@suse.com, ysaito@hpl.hp.com
Subject: Re: Pending AIO work/patches
Date: Mon, 20 Jun 2005 11:51:17 -0700	[thread overview]
Message-ID: <42B71025.6040006@zabbo.net> (raw)
In-Reply-To: <20050620181007.GA4031@kvack.org>


>>(6) epoll - AIO integration (Zach Brown/Feng Zhou/wli)
>>	Status: Needs resurrection ?
> 
> 
> What are folks thoughts in this area?  Zach's patches took the approach of 
> making multishot iocbs possible, which helped avoid the overhead of plain 
> aio_poll's command setup, which was quite visible in pipetest.  Zach -- did 
> you do any benchmarking on your aio-epoll patches?

No, what little work I did on this was just pushing for stable
functionality.  I had a little test app that was still missing event
delivery occasionally.  I'm sure it'd be easy enough to track down.  It
still seems like a pretty reasonable translation of epoll event delivery
through the aio completion queue.  I'm not thrilled with the epoll edge
delivery semantics, though, it would be nice to make duplicate event
generation contigent on servicing an initial event.  EPOLLIN being
throttled until read activity is seen on the fd, that kind of thing.
Nontrivial work, of course.

>>(7) Vector AIO (aio readv/writev) (Yasushi Saito)
>>	Status: Needs resurrection ?
> 
> Zach also made some noises about this recently...

Yeah, I've got a patch working that adds CMD_AIO_P{WRITE,READ}V for ext3
via some aio->aio_p{read,werive}v ops.  It's currently against some
distro 2.6, but I'll port it up to current and post the patch.  It seems
pretty noncontroversial -- one obviously wants to scatter/gather
file-contiguous IO with tiny iovec elements, which bubble down well to
the generic fs/block helpers, rather than trying to get the various
layers to merge many large iocb submissions that can be found to be
file-contiguous.

- z

  reply	other threads:[~2005-06-20 18:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-20 12:01 Pending AIO work/patches Suparna Bhattacharya
2005-06-20 13:13 ` Trond Myklebust
2005-06-20 14:32 ` Sébastien Dugué
2005-06-20 16:01 ` [PATCH 0/6] Integrate AIO with wait-bit based filtered wakeups Suparna Bhattacharya
2005-06-20 16:20   ` [PATCH 1/6] Add a wait queue argument to wait_bit action() Suparna Bhattacharya
2005-06-20 16:24   ` [PATCH 2/6] Rename __lock_page to lock_page_slow Suparna Bhattacharya
2005-06-28 16:52     ` Zach Brown
2005-06-29  9:51       ` Suparna Bhattacharya
2005-07-24 22:17     ` Christoph Hellwig
2005-07-24 22:36       ` Christoph Hellwig
2005-07-26  1:10         ` Suparna Bhattacharya
2005-06-20 16:28   ` [PATCH 3/6] Interfaces to initialize and to test a wait_bit key Suparna Bhattacharya
2005-06-20 16:30   ` [PATCH 4/6] Add default io wait bit field in task struct Suparna Bhattacharya
2005-06-20 16:33   ` [PATCH 5/6] AIO wait bit and AIO wake bit for filtered wakeups Suparna Bhattacharya
2005-06-20 16:36   ` [PATCH 6/6] AIO wait page and AIO lock page Suparna Bhattacharya
2005-06-30 15:49   ` [PATCH 0/6] Integrate AIO with wait-bit based filtered wakeups Sébastien Dugué
2005-07-01  7:37     ` Suparna Bhattacharya
2005-06-20 18:10 ` Pending AIO work/patches Benjamin LaHaise
2005-06-20 18:51   ` Zach Brown [this message]
2005-06-21  7:36   ` Sébastien Dugué
2005-06-21 19:03 ` William Lee Irwin III
2005-06-24 10:49 ` [PATCH 0/2] Buffered filesystem AIO read/write Suparna Bhattacharya
2005-06-24 11:21   ` [PATCH 1/2] Filesystem AIO read Suparna Bhattacharya
2005-06-24 11:40   ` [PATCH 2/2] Filesystem AIO write Suparna Bhattacharya
2005-06-24 16:10   ` [PATCH 0/2] Buffered filesystem AIO read/write Jeremy Allison

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=42B71025.6040006@zabbo.net \
    --to=zab@zabbo.net \
    --cc=bcrl@kvack.org \
    --cc=linux-aio@kvack.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mason@suse.com \
    --cc=suparna@in.ibm.com \
    --cc=wli@holomorphy.com \
    --cc=ysaito@hpl.hp.com \
    /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.