Re: [9fans] fuse bashing

[Eric Van Hensbergen <ericvh@gmail.com>]

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 <lucho@gmx.net> 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 for 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+fusexmpl
> > > 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 0maxresident)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 0maxresident)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
>