Date: Sun, 8 Sep 1996 14:37:53 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: michaelh@cet.co.jp (Michael Hancock) Cc: terry@lambert.org, koshy@india.hp.com, jkh@time.cdrom.com, jehamby@lightside.com, imp@village.org, lada@ws2301.gud.siemens.co.at, dennis@etinc.com, hackers@FreeBSD.org Subject: Re: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions)) Message-ID: <199609082137.OAA03696@phaeton.artisoft.com> In-Reply-To: <Pine.SV4.3.93.960908105046.7379D-100000@parkplace.cet.co.jp> from "Michael Hancock" at Sep 8, 96 10:55:41 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. The minus in the SVR4 approach is mostly a result of the way symlinks are handled, IMO. The non-iteration fix for the BSD namei() is possible, but you rarely ever see a case in practice where it eats intervening path components; in fact, given the way mount pount traversal is handled, it would take a lot of work to make this go and still handle the covered vnode case. Also in practice, I believe cache locality for path components prior to the terminal component is very high. This means thast a per component lookup can be a *very* big win after the first lookup primes the name cache... probably a bigger win than the penalty. 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?199609082137.OAA03696>