lkml.org 
[lkml]   [2004]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: delay in block_read_full_page()
    Michael Mesnier <mmesnier@ece.cmu.edu> wrote:
    >
    > Hello,
    >
    > Please cc: me directly in your response.
    >
    > I'm running into some trouble with an installable file system I'm
    > writing. In myfs_readpage() I simply return block_read_full_page() which
    > subsequently calls myfs_get_block(). However, there's a delay before
    > the I/O actually gets issued to the device. Running sync from the
    > command line causes the I/O to get issued immediately, so the sync call
    > (even it there aren't dirty buffers) also manages to schedule any
    > outstanding read I/Os. How should my fs indicate to the vfs that these
    > read I/Os need to be issued immediately after my_readpage() is called?

    Normally we leave the I/O pending in the expectation that more readpage()
    requests will occur. This allow us to merge things in the disk request
    queues. We'll actually submit the I/O to the device if:

    a) There's a lot of it pending or

    b) There haven't been any more readpage() calls for a while or

    c) Someone actually wants to wait on the I/O (say, via lock_page())

    It is unusual that you want this I/O to kick off immediately. You will
    probably find that blk_run_backing_dev() will do what you want.


    That's all for a 2.6 kernel - you didn't specify. It it's a 2.4 kernel
    then you'll need to use run_task_queue(&tq_disk) to flush the queued I/O
    requests.
    -
    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 14:07    [W:4.679 / U:1.784 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site