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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/