delay in block_read_full_page()

delay in block_read_full_page()

[Michael Mesnier]

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?

Thanks in advanced,

-Mike

static int myfs_get_block(struct inode *inode, long iblock, struct 
buffer_head *bh_result, int create) {
    bh_result->b_dev = inode->i_dev;
    bh_result->b_blocknr = iblock;
    bh_result->b_state |= (1UL << BH_Mapped);
    return 0;
}

static int myfs_readpage(struct file *file, struct page *page) {
    return block_read_full_page(page,myfs_get_block);
}

Re: delay in block_read_full_page()

[Andrew Morton]

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.

Re: delay in block_read_full_page()

[Michael Mesnier]

Andrew,

Thanks for the help.  I found my problem.  

I forgot to add "sync_page: block_sync_page" into my address space 
operations.  As a result, the device queue was plugged into until 
something else (e.g., kupdate) released the I/O via 
"run_task_queue(&tq_disk)."

Regards,

Mike


Andrew Morton wrote:

>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.
>  
>