From owner-freebsd-hackers Sun Sep 8 14:46:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA27021 for hackers-outgoing; Sun, 8 Sep 1996 14:46:50 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA27014 for ; Sun, 8 Sep 1996 14:46:46 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA03696; Sun, 8 Sep 1996 14:37:53 -0700 From: Terry Lambert Message-Id: <199609082137.OAA03696@phaeton.artisoft.com> Subject: Re: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions)) To: michaelh@cet.co.jp (Michael Hancock) Date: Sun, 8 Sep 1996 14:37:53 -0700 (MST) 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 In-Reply-To: from "Michael Hancock" at Sep 8, 96 10:55:41 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > 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.