From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 24 Jan 2006 19:42:24 -0600 From: Eric Van Hensbergen To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] fuse bashing In-Reply-To: <20060125014026.GA9487@ionkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060124201041.5A72A78FBB@dexter-peak.quanstro.net> <20060125002544.GA8690@ionkov.net> <20060125013144.B3BE778FBB@dexter-peak.quanstro.net> <20060125014026.GA9487@ionkov.net> Topicbox-Message-UUID: e6f5f194-ead0-11e9-9d60-3106f5b1d025 Big reason is likely the page-cache. FUSE can take full advantage while we take overhead trying to circumvent it. Perhaps its time to look at putting cacheing back into v9fs. We really need to do a performance drill-down again with a cross-section of workloads. I'd like to look at SDET (which is essentially a software development based benchmark). I'll see if I can dig up source code. Likely we'll need dcache and pagecache before we'll have decent numbers, but I'd like to see how close we come without them. -eric On 1/24/06, Latchesar Ionkov wrote: > I didn't try tapefs, but ramfs in p9p is slower than u9fs (even after the > fid lookup is improved). > > Thanks, > Lucho > > On Tue, Jan 24, 2006 at 07:31:44PM -0600, erik quanstrom said: > > > > On Tue Jan 24 18:24:33 CST 2006, lucho@gmx.net wrote: > > > On Tue, Jan 24, 2006 at 02:10:41PM -0600, quanstro@quanstro.net said: > > > > On Mon Jan 23 20:21:36 CST 2006, lucho@gmx.net wrote: > > > > > On Mon, Jan 23, 2006 at 12:06:09PM -0500, Russ Cox said: > > > > > > It appears to match the kernel better, so the implementation > > > > > > should be simpler. (As soon as you want to talk between > > > > > > > > > > It is much simpler (and probably faster), and that's a big win fo= r FUSE: > > > > > > > > > > $ cat fs/fuse/*.[ch] | wc -l > > > > > 4073 > > > > > > > > > > $ cat 9p/*.[ch] | wc -l > > > > > 7271 > > > > > > > > why do you assume that line count is porportinal to > > > > speed of execution or complexity? > > > > > > Because it doesn't need to convert an alien protocol to Linux VFS. It > > > doesn't need to care about converting error strings to error codes, > > > architecture independent format for the values etc. > > > > even so, these sound like simple translations. they may produce more > > code, but i'm not sure they add complexity. > > > > > It doesn't need to care > > > about unix and tcp sockets. In fact I tested the speed of fuse+fusexm= pl > > > compared with v9fs+u9fs, and fuse is noticeably faster. > > > > why didn't you say so? ;-) > > > > i don't use u9fs; was there any indication that v9fs in the kernel was = slow? > > have you tried any p9p fileservers? tapefs seemed speedy enough: > > > > ; 9p ls tapefs > > --rw-r--r-- M 0 1000 100 6749246 Feb 5 1998 cyberbit.zip > > ; time 9p read tapefs/cyberbit.zip > /dev/null > > 0.18user 0.20system 0:01.07elapsed 36%CPU (0avgtext+0avgdata 0maxreside= nt)k > > 0inputs+0outputs (0major+404minor)pagefaults 0swaps > > > > ; time cat 9/tapefs/cyberbit.zip > /dev/null > > 0.00user 0.01system 0:01.15elapsed 1%CPU (0avgtext+0avgdata 0maxresiden= t)k > > 0inputs+0outputs (0major+146minor)pagefaults 0swaps > > > > > > > > If FUSE doesn't handle the interrupts well, that in part explains why= is it > > > smaller. The proper signal handling is one of the most complex parts = in v9fs. > > > > > > Thanks, > > > Lucho >