public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org,
	linux-aio@kvack.org
Subject: Re: [RFC][PATCH] 2.5.37 patch for making DIO async
Date: Fri, 20 Sep 2002 16:31:31 -0700	[thread overview]
Message-ID: <3D8BAFD3.6E4F495D@digeo.com> (raw)
In-Reply-To: 200209202219.g8KMJ2x26455@eng2.beaverton.ibm.com

Badari Pulavarty wrote:
> 
> Hi,
> 
> Here is 2.5.37 patch for making DIO code async. Waiting for IO completion
> will be done at the higher level. This patch adds support for RAW Async IO.
> We already posted performance comparisions numbers earlier on 2.5.35.
> 
> ISSUE: This patch does set_page_dirty() on a page, from the interrupt
> handler (io completion handler). Which is NOT safe.  Any suggestions
> on (where and how to) moving this outside the interrupt handler ?
> Ben & Andrew, any ideas ?
> 

No particularly good ones, I'm afraid.  Options appear to be:

1: Lose data if the pages are swapcache or pagecache.

2: Make mapping->page_lock and mapping->private_lock irq-safe,
   and mandate that a_ops->set_page_dirty be callable from 
   interrupt context.

3: Hang onto the BIOs and find a process somewhere to mark the
   pages dirty and then release them after IO has completed.

None of these are particularly palatable.  But if this is a
showstopper for async IO against raw devices, and a showstopper
for async IO against O_DIRECT blockdevs and a showstopper for
async IO against O_DIRECT files (is it?) then I guess we clench
the teeth and go for option 2.

Holding onto gazillions of BIOs and punting it all up to keventd
some time in the future would be lame.  Making those locks and these
codepaths irq-safe is consistent with the general tougher, tighter
and more async direction in which the 2.5 IO paths are headed, so...

With the radix-tree gang lookup and truncate rework I expect that
the maximum hold time of those locks is miniscule, so interrupt
latency isn't a concern here.  (It would be 50 milliseconds or
more at present...)

ho-hum.  I'll do the patch.

      reply	other threads:[~2002-09-20 23:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-20 22:19 [RFC][PATCH] 2.5.37 patch for making DIO async Badari Pulavarty
2002-09-20 23:31 ` Andrew Morton [this message]

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=3D8BAFD3.6E4F495D@digeo.com \
    --to=akpm@digeo.com \
    --cc=linux-aio@kvack.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=pbadari@us.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