lkml.org 
[lkml]   [2003]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 13:33    [W:0.022 / U:30.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site