Date: Sun, 8 Sep 1996 10:55:41 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Terry Lambert <terry@lambert.org> Cc: A JOSEPH KOSHY <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: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions)) Message-ID: <Pine.SV4.3.93.960908105046.7379D-100000@parkplace.cet.co.jp> In-Reply-To: <199609061802.LAA11517@phaeton.artisoft.com>
index | next in thread | previous in thread | raw e-mail
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. Regards, Mike Hancockhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960908105046.7379D-100000>