mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: suparna@in.ibm.com
Cc: bcrl@redhat.com, linux-aio@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [Patch 2/2] Retry based aio read - filesystem read changes
Date: Wed, 5 Mar 2003 02:42:54 -0800	[thread overview]
Message-ID: <20030305024254.7f154afc.akpm@digeo.com> (raw)
In-Reply-To: <20030305150026.B1627@in.ibm.com>

Suparna Bhattacharya <suparna@in.ibm.com> wrote:
>
> +extern int FASTCALL(aio_wait_on_page_bit(struct page *page, int bit_nr));
> +static inline int aio_wait_on_page_locked(struct page *page)

Oh boy.

There are soooo many more places where we can block:

- write() -> down(&inode->i_sem)

- read()/write() -> read indirect block -> wait_on_buffer()

- read()/write() -> read bitmap block -> wait_on_buffer()

- write() -> allocate block -> mark_buffer_dirty() ->
	balance_dirty_pages() -> writer throttling

- write() -> allocate block -> journal_get_write_access()

- read()/write() -> update_a/b/ctime() -> journal_get_write_access()

- ditto for other journalling filesystems

- read()/write() -> anything -> get_request_wait()
  (This one can be avoided by polling the backing_dev_info congestion
   flags)

- read()/write() -> page allocator -> blk_congestion_wait()

- write() -> balance_dirty_pages() -> writer throttling

- probably others.

Now, I assume that what you're looking for here is an 80% solution, but it
seems that a lot more changes will be needed to get even that far.

And given that a single kernel thread per spindle can easily keep that
spindle saturated all the time, one does wonder "why try to do it this way at
all"?

  reply	other threads:[~2003-03-05 10:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-05  9:17 [RFC][Patch] Retry based aio read for filesystems Suparna Bhattacharya
2003-03-05  9:26 ` [Patch 1/2] Retry based aio read - core aio changes Suparna Bhattacharya
2003-03-14 13:23   ` Suparna Bhattacharya
2003-03-05  9:30 ` [Patch 2/2] Retry based aio read - filesystem read changes Suparna Bhattacharya
2003-03-05 10:42   ` Andrew Morton [this message]
2003-03-05 12:14     ` Suparna Bhattacharya
2003-03-31 18:32       ` Janet Morgan
2003-03-31 19:11         ` William Lee Irwin III
2003-03-31 19:16           ` Benjamin LaHaise
2003-03-31 19:07             ` Janet Morgan
2003-04-01 20:24               ` Benjamin LaHaise
2003-03-31 19:17             ` William Lee Irwin III
2003-03-31 19:25               ` Benjamin LaHaise
2003-04-07  3:51             ` Suparna Bhattacharya
2003-03-05 23:00 ` [RFC][Patch] Retry based aio read for filesystems Janet Morgan

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=20030305024254.7f154afc.akpm@digeo.com \
    --to=akpm@digeo.com \
    --cc=bcrl@redhat.com \
    --cc=linux-aio@kvack.org \
    --cc=linux-kernel@vger.kernel.org \
    --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

Powered by JetHome