Re: delay in block_read_full_page()

[Michael Mesnier <mmesnier@ece.cmu.edu>]

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