Re: [ATTEND][LSF/MM TOPIC] FUSE: write-back cache policy and other improvements

["Maxim V. Patlasov" <mpatlasov@parallels.com>]

Adding linux-mm to cc:. One more point to discuss:

* balance_dirty_pages(): should we account NR_WRITEBACK_TEMP there? 
Currently, any FUSE user may consume arbitrary amount of RAM (stuck in 
kernel FUSE writeback) by intensive write to a huge mmap-ed area.

02/13/2013 07:08 PM, Maxim V. Patlasov пишет:
> Hi,
>
> I'm interested in attending to discuss the latest advances in 
> accelerating FUSE and making it more friendly to distributed 
> file-systems. I'd like to propose and participate in the following 
> discussions in the upcoming LSF/MM:
>
> * write-back cache policy: one of the problems with the existing FUSE 
> implementation is that it uses the write-through cache policy which 
> results in performance problems on certain workloads. A good solution 
> of this is switching the FUSE page cache into a write-back policy. 
> With this file data are pushed to the userspace with big chunks which 
> lets the FUSE daemons handle requests in a more efficient manner.
>
> * optimize scatter-gather direct IO: dio performance can be improved 
> significantly by stuffing many io-vectors  into a single fuse request. 
> This is especially the case for device virtualization thread 
> performing i/o on behalf of virtual-machine it serves.
>
> * process direct IO asynchronously: both AIO and ordinary synchronous 
> direct IO can be boosted by submitting fuse requests in non-blocking 
> way (where it's possible) and either returning -EIOCBQUEUED or waiting 
> for their completions synchronously.
>
> * synchronous close(2): currently, in-kernel fuse sends release 
> request to userspace and returns without waiting for ACK from 
> userspace. Consequently, there is a gap when user regards the file 
> released while userspace fuse is still working on it. This leads to 
> unnecessary synchronization complications for file-systems with shared 
> access. That behaviour can be fixed by making close(2) synchronous.
>
> * throttle request allocations: currently, in-kernel fuse throttles 
> allocations of all fuse requests. Switching to the policy where only 
> background requests are throttled would improve the latency of 
> synchronous requests and resolve thundering herd problem of waking up 
> all threads blocked on fuse request allocations.
>
> Thanks,
> Maxim
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html