From: Jens Axboe <axboe@suse.de>
To: Suparna Bhattacharya <suparna@in.ibm.com>
Cc: Benjamin LaHaise <bcrl@redhat.com>,
Shailabh Nagar <nagar@watson.ibm.com>,
Linux Aio <linux-aio@kvack.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] 2.5 port of aio-20020619 for raw devices
Date: Fri, 13 Sep 2002 15:44:04 +0200 [thread overview]
Message-ID: <20020913134404.GG935@suse.de> (raw)
In-Reply-To: <20020913184652.C2758@in.ibm.com>
On Fri, Sep 13 2002, Suparna Bhattacharya wrote:
> On Thu, Sep 12, 2002 at 02:35:40PM -0400, Benjamin LaHaise wrote:
> > On Thu, Sep 12, 2002 at 02:21:08PM -0400, Shailabh Nagar wrote:
> > > I just did a rough port of the raw device part of the aio-20020619.diff
> > > over to 2.5.32 using the 2.5 aio API published so far. The changeset
> > > comments are below. The patch hasn't been tested. Its only guaranteed
> > > to compile.
> > >
> > > I'd like to reiterate that this is not a fork of aio kernel code
> > > development or any attempt to question Ben's role as maintainer ! This
> > > was only an exercise in porting to enable a comparison of the older
> > > (2.4) approach with whatever's coming soon.
> > >
> > > Comments are invited on all aspects of the design and implementation.
> >
> > The generic aio <-> kvec functions were found to not work well, and
> > the chunking code needs to actually pipeline data for decent io thruput.
> > Short story: the raw device code must be rewritten using the dio code
> > that akpm introduced.
>
> How async (degree on non-blocking nature of steps in the async state
> machine) do we want to be when we use the dio pipelining code ?
> (besides making the wait for dio completion bit async, of course)
>
> Some key places where we can potentially block are when mapping
> the user pages, as part of get_blocks, when alloc'ing a bio,
> when issuing submit_bio (i.e. waiting for the request pipeline
> to drain out or free up slots). I guess, at least the last one
> would be addressed ... not sure what the plans for the rest
> are.
alloc_bio non-blocking can be done by caller himself, submit_bio
non-blocking can be assured with BIO_RW_AHEAD.
--
Jens Axboe
next prev parent reply other threads:[~2002-09-13 13:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-12 18:21 [PATCH] 2.5 port of aio-20020619 for raw devices Shailabh Nagar
2002-09-12 18:35 ` Benjamin LaHaise
2002-09-12 18:37 ` Shailabh Nagar
2002-09-12 18:53 ` Benjamin LaHaise
2002-09-12 19:31 ` Shailabh Nagar
2002-09-12 19:40 ` Benjamin LaHaise
2002-09-13 13:16 ` Suparna Bhattacharya
2002-09-13 13:44 ` Jens Axboe [this message]
2002-09-13 19:34 ` Andrew Morton
2002-09-13 19:57 ` Benjamin LaHaise
2002-09-13 20:03 ` 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=20020913134404.GG935@suse.de \
--to=axboe@suse.de \
--cc=bcrl@redhat.com \
--cc=linux-aio@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nagar@watson.ibm.com \
--cc=suparna@in.ibm.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.