Date: Sun, 8 Sep 1996 18:47:58 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Terry Lambert <terry@lambert.org> Cc: FreeBSD Hackers <hackers@FreeBSD.org> Subject: Re: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions)) Message-ID: <Pine.SV4.3.93.960908181852.8929B-100000@parkplace.cet.co.jp> In-Reply-To: <Pine.SV4.3.93.960908105046.7379D-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 8 Sep 1996, Michael Hancock wrote: > On Fri, 6 Sep 1996, Terry Lambert wrote: > > > > Surprisingly `namei' turned out to be the single biggest contributor to > > > time spent in the kernel. > [snip] > > The namei() call tends to copy the path string around, and so is a > > big offender; this is correctable with a couple of interface changes; > > the nameifree() change drops it about 10%, for instance, by moving > > the alloc/free operation to the same API level, and reducing the > > extra testing that has to go on everywhere in the error cases. > > > > Changing the path string into a pre-parsed list of path components is > > about another 6% win, and you can get another 8% by putting in the > > change to not go through with the allocation on a preexisting element. > > This complicated parsing of symbolic links, since it means you have > > to loop-unroll the mutual recusrsion (which is how symbolic links > > are currently implemented). To avoid using too much kernel stack, > > you have to reduce the stack usage to get there -- another reason > > for a pre-parsed list not allocated on the stack. > > How would it compare to a SYSV lookuppn() which works component by > component? Namei can handle components up to mount boundaries requiring > less calls. I should clarify this. Namei allows the file system dependent layer make the decision to go component by component or by components up to a mount point. nfs_lookup requires component by component, but presumably ufs_lookup can operate on chunks of the pathname up to a mount point. Example: /var/spool/news/comp/unix/bsd/freebsd/misc ^ ^ sd1 sd2 parse pathname into components foreach component (9) VOP_LOOKUP(component[i]) or while pathname not processed (3?) VOP_LOOKUP(pathname) I might be off by one, I'm not entirely clear how many times VOP_LOOKUP gets called in the cases above. Isn't the biggest problem, with the namei way of doing things, the lock put on the directory? A directory will be locked between operations, even if the caller blocks. The directory is locked even for reads which serializes access to the directory. It would be interesting to see if using multiple-reader/single writer locks would improve performance here. Regards, Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960908181852.8929B-100000>