Date: Fri, 15 Dec 1995 11:13:42 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: davidg@root.com Cc: terry@lambert.org, current@freebsd.org Subject: Re: VOP_READIR revisited Message-ID: <199512151813.LAA04483@phaeton.artisoft.com> In-Reply-To: <199512150112.RAA00156@corbin.Root.COM> from "David Greenman" at Dec 14, 95 05:12:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >So you basically think passing around a buffer pointer instead of a > >buffer, and converting it in the copyout case is a more of a kludge > >than copying to a local buffer and maintaining malloc'ed arrays of > >cookies at every stacked FS layer, the syscall, and NFS server > >export code. > > > >I must be missing something that is obvious to you. Please > >enlighten us. > > No, basically I think adding another VOP call significantly complicates > the code both in its use and understanding of function...not to mention > performance. Couldn't I make the same argument about the addition of cookies to the VOP_READDIR interface in the first place? Consider the additional arguments, the addition assignments at the VOP_READDIR level, and the additional pushes at to VOCALL, the additional local variable assignments, the additional pointer compares, and the additional references to numcookies++ (a local variable used by many FS's to implement a cookie count for the malloc, even when cookies are not being used). I think I can find a replacement for the 12 cycles + argument push + ESP add after call that would be used by another VOP by looking no further than the NULL cookie pointer case. I think I can actually argue "performance gain" if the VOP_ call is inlined like it's supposed to be according to the compiler directive (dropping the cost the the local argument assigns and 6 cycles). As you point out, cookies are only used in the NFS case (at present), so the overhead involved in cookie processing for a NULL cookie is nothing but pure waste in the vast majority of cases... and in the cases where it isn't just naked overhead, the limiting factor on user response is going to be wire time anyway, so the algorith could be extremely pessimal for the cookie case and it would still be a win to somehow seperate or otherwise reduce the default case. I really don't see the overhead argument. And as I pointed out by documenting the current cache_* call interactions with the underlying file systems, there is a *great* deal of extra complication, as well as 3 missed caching opportunities in the cache implementation (starting with the need for each FS to independently implement cache usage instead of it being implicit in the namei/lookup coroutine mechanism). So I really don't see the complexity argument, either. If it applies, it must apply uniformly, across the board, to all portions of the kernel. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512151813.LAA04483>