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"?
next prev parent 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