fuse, readpage and readahead

fuse, readpage and readahead

[Jarzmik, Robert]

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 ?

Cheers.

--
Robert

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: fuse, readpage and readahead

[Miklos Szeredi]

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
>

RE: fuse, readpage and readahead

[Jarzmik, Robert]

> -----Original Message-----
> From: Miklos Szeredi [mailto:miklos@szeredi.hu]
> Sent: Tuesday, February 05, 2013 3:12 PM
> To: Jarzmik, Robert
> Cc: linux-fsdevel@vger.kernel.org
> Subject: Re: fuse, readpage and readahead
> 
.. zip ...
> On Wed, Nov 28, 2012 at 5:55 PM, Jarzmik, Robert
> > 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
> >
...zip...
> > 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().

OK, I think I understand. You mean that in fuse_send_readpages(), if 
(fc->async_read) is true, fuse_request_send_background() will be used
instead of fuse_request_send().

Therefore I think you assume from the backtrace I showed that 
(struct fuse_con *)->async_read was false, ie. that the reponse to the
initial FUSE_INIT by the sdcard daemon has not set FUSE_ASYNC_READ flag.

Thanks for you help.

Cheers.

--
Robert

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.