Re: fuse, readpage and readahead

[Miklos Szeredi <miklos@szeredi.hu>]

On Wed, Nov 28, 2012 at 5:55 PM, Jarzmik, Robert
<robert.jarzmik@intel.com> wrote:
> Hi Miklos,
>
> I would like to understand the "synchronous" aspect of fuse readahead.
> The usecase I have is :
>  - /sdcard is the FUSE mounted FS relying on /data, which is an ext4
>    Filesystem on /dev/block/mmcblk0p1
>  - one process is reading an mp3 file from a FUSE filesystem backed by
>    a local ext4 system
>    aplay /sdcard/Music/ElvisIsBack.mp3
>  - another process is : dd if=/dev/zero of=/data/hog1
>
> In my test, I came across the following scenario recently :
>
> filemap_fault()
> ...
>   do_generic_file_read()
>     page_cache_async_readahead()
>       ondemand_readahead()
>         __do_page_cache_readahead()
>           read_pages()
>             fuse_readpages()
>               fuse_request_send() => takes around 500ms
>
> Here, fuse_request_send() will block as long as no reponse comes back
> from the backing fuse (which is a local ext4 system). Correct me if
> I'm wrong, but the synchronous fuse_request_send() is chosen on file
> basis.
>
> The effect is that in filemap_fault() path, the process is blocked
> for 500ms in my scenario, waiting for the readahead to complete,
> while the first pagecache was succesfully found (I have an Ftrace
> which tells me so). Therefore, I have a small audio glitch.
>
> My question is : is this the expected behaviour, ie. that read-ahead
> blocks the filemap fault path ? If this was already discussed before,
> could you please give me a link to the discussion ?

Readahead is asynchronous by default.  Synchronous mode may be forced
with "-osync_read".  See
linux/fs/fuse/file.c:fuse_send_readpages().

Thanks,
Miklos
>