On Wed, Nov 28, 2012 at 5:55 PM, Jarzmik, Robert <robert.jarzmik@xxxxxxxxx> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
