linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Jens Axboe <axboe@suse.de>
Cc: Suparna Bhattacharya <suparna@in.ibm.com>,
	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 12:34:36 -0700	[thread overview]
Message-ID: <3D823DCC.3E303941@digeo.com> (raw)
In-Reply-To: 20020913134404.GG935@suse.de

Jens Axboe wrote:
> 
> ...
> alloc_bio non-blocking can be done by caller himself, submit_bio
> non-blocking can be assured with BIO_RW_AHEAD.

I haven't really found that to be usable - by the time you've
called submit_bio() it's just waaaay too late to back out and
undo everything.  Mark pages dirty again, unlock them, clear the
writeback bits, tell the caller that we really didn't write these
many pages, tell the caller that things aren't working out, stop
sending us pages, etc.

It's made harder by the fact that submit_bio() always returns "1".  So
you need to work out what happened in the bi_end_io() handler and
pass all that back again.  And somehow work out whether it was a failed
WRITEA and not an IO error...

That's why I added the ability to ask "is this mapping's queue congested".
It is much simpler to use and test from the perspective of the upper layers.

It has the disadvantage that we may have some data which is mergeable,
and would in fact nonblockingly fit into a "congested" queue.  Don't
know if that makes a lot of difference in practice.

But there are some more things we can do to improve IO scheduling from the
top layer.  The most prominent of these is to write back the blockdev
mapping's dirty pages in pgoff_t order (ie: LBA order) rather than in
chronological mapping->dirty_pages order.  That's happening, slowly, but
involves significant surgery on radix_tree_brains.

  reply	other threads:[~2002-09-13 19:30 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
2002-09-13 19:34       ` Andrew Morton [this message]
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=3D823DCC.3E303941@digeo.com \
    --to=akpm@digeo.com \
    --cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).