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

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

[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

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

[Maxim V. Patlasov]

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