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