From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Maxim V. Patlasov" Subject: Re: [ATTEND][LSF/MM TOPIC] FUSE: write-back cache policy and other improvements Date: Thu, 28 Feb 2013 16:19:10 +0400 Message-ID: <512F4B3E.6030409@parallels.com> References: <511BAC51.4030309@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "linux-fsdevel@vger.kernel.org" , "fuse-devel@lists.sourceforge.net" , To: Return-path: Received: from relay.parallels.com ([195.214.232.42]:42600 "EHLO relay.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752484Ab3B1MSz (ORCPT ); Thu, 28 Feb 2013 07:18:55 -0500 In-Reply-To: <511BAC51.4030309@parallels.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Adding linux-mm to cc:. One more point to discuss: * balance_dirty_pages(): should we account NR_WRITEBACK_TEMP there?=20 Currently, any FUSE user may consume arbitrary amount of RAM (stuck in=20 kernel FUSE writeback) by intensive write to a huge mmap-ed area. 02/13/2013 07:08 PM, Maxim V. Patlasov =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Hi, > > I'm interested in attending to discuss the latest advances in=20 > accelerating FUSE and making it more friendly to distributed=20 > file-systems. I'd like to propose and participate in the following=20 > discussions in the upcoming LSF/MM: > > * write-back cache policy: one of the problems with the existing FUSE= =20 > implementation is that it uses the write-through cache policy which=20 > results in performance problems on certain workloads. A good solution= =20 > of this is switching the FUSE page cache into a write-back policy.=20 > With this file data are pushed to the userspace with big chunks which= =20 > lets the FUSE daemons handle requests in a more efficient manner. > > * optimize scatter-gather direct IO: dio performance can be improved=20 > significantly by stuffing many io-vectors into a single fuse request= =2E=20 > This is especially the case for device virtualization thread=20 > performing i/o on behalf of virtual-machine it serves. > > * process direct IO asynchronously: both AIO and ordinary synchronous= =20 > direct IO can be boosted by submitting fuse requests in non-blocking=20 > way (where it's possible) and either returning -EIOCBQUEUED or waitin= g=20 > for their completions synchronously. > > * synchronous close(2): currently, in-kernel fuse sends release=20 > request to userspace and returns without waiting for ACK from=20 > userspace. Consequently, there is a gap when user regards the file=20 > released while userspace fuse is still working on it. This leads to=20 > unnecessary synchronization complications for file-systems with share= d=20 > access. That behaviour can be fixed by making close(2) synchronous. > > * throttle request allocations: currently, in-kernel fuse throttles=20 > allocations of all fuse requests. Switching to the policy where only=20 > background requests are throttled would improve the latency of=20 > synchronous requests and resolve thundering herd problem of waking up= =20 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx196.postini.com [74.125.245.196]) by kanga.kvack.org (Postfix) with SMTP id CF2806B0005 for ; Thu, 28 Feb 2013 07:18:52 -0500 (EST) Message-ID: <512F4B3E.6030409@parallels.com> Date: Thu, 28 Feb 2013 16:19:10 +0400 From: "Maxim V. Patlasov" MIME-Version: 1.0 Subject: Re: [ATTEND][LSF/MM TOPIC] FUSE: write-back cache policy and other improvements References: <511BAC51.4030309@parallels.com> In-Reply-To: <511BAC51.4030309@parallels.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: lsf-pc@lists.linux-foundation.org Cc: "linux-fsdevel@vger.kernel.org" , "fuse-devel@lists.sourceforge.net" , linux-mm@kvack.org 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 D?D,N?DuN?: > 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org