Messages in this thread | | | Date | Wed, 5 Mar 2003 02:42:54 -0800 | From | Andrew Morton <> | Subject | Re: [Patch 2/2] Retry based aio read - filesystem read changes |
| |
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"? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |