On Tue, Sep 29, 2020 at 03:49:04PM +0200, Miklos Szeredi wrote: > On Tue, Sep 29, 2020 at 3:18 PM Vivek Goyal <vgo...@redhat.com> wrote: > > > - virtiofs cache=none mode is faster than cache=auto mode for this > > workload. > > Not sure why. One cause could be that readahead is not perfect at > detecting the random pattern. Could we compare total I/O on the > server vs. total I/O by fio?
Hi Miklos, I will instrument virtiosd code to figure out total I/O. One more potential issue I am staring at is refreshing the attrs on READ if fc->auto_inval_data is set. fuse_cache_read_iter() { /* * In auto invalidate mode, always update attributes on read. * Otherwise, only update if we attempt to read past EOF (to ensure * i_size is up to date). */ if (fc->auto_inval_data || (iocb->ki_pos + iov_iter_count(to) > i_size_read(inode))) { int err; err = fuse_update_attributes(inode, iocb->ki_filp); if (err) return err; } } Given this is a mixed READ/WRITE workload, every WRITE will invalidate attrs. And next READ will first do GETATTR() from server (and potentially invalidate page cache) before doing READ. This sounds suboptimal especially from the point of view of WRITEs done by this client itself. I mean if another client has modified the file, then doing GETATTR after a second makes sense. But there should be some optimization to make sure our own WRITEs don't end up doing GETATTR and invalidate page cache (because cache contents are still valid). I disabled ->auto_invalid_data and that seemed to result in 8-10% gain in performance for this workload. Thanks Vivek