NetBSD Problem Report #15179

Received: (qmail 18475 invoked from network); 8 Jan 2002 13:30:02 -0000
Message-Id: <200201081329.g08DTCY10834@sam.few.eur.nl>
Date: Tue, 8 Jan 2002 14:29:12 +0100 (MET)
From: Paul Kranenburg <pk@cs.few.eur.nl>
Reply-To: pk@cs.few.eur.nl
To: gnats-bugs@gnats.netbsd.org
Subject: make(1) no longer uses its file caches effectively
X-Send-Pr-Version: 3.95

>Number:         15179
>Category:       toolchain
>Synopsis:       make(1) no longer uses its file caches effectively
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 08 13:31:00 +0000 2002
>Closed-Date:    
>Last-Modified:  Tue Feb 12 08:58:34 +0000 2002
>Originator:     Paul Kranenburg
>Release:        NetBSD-current, Jan 2002
>Organization:

>Environment:

>Description:
	make(1) caches the contents of the object and include directories
	so it can check efficiently for the existence of the files it is
	looking for when checking dependencies or including other makefiles.
	These caches are no longer used effectively resulting in a tremendous
	increase in the number of stat(2) system calls. This causes a
	noticeable slowdown especially when a large number of source and
	object files are involved such as in a kernel build directory.
>How-To-Repeat:
	Look at the ouput of `ktrace make' on some kernel build directory.
	Note the number of stat(2) calls resulting from suffix rule processing,
	which amount to 15 for every object file.
>Fix:
	none provided.
	Yet I note that this problem appeared with revision 1.27
	of src/usr.bin/make/dir.c (see also PR15178).
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: pk 
State-Changed-When: Wed Jan 30 00:59:58 PST 2002 
State-Changed-Why:  
A closer look at the problem that prompted revision 1.27 of dir.c: 

When looking up names which directory components (i.e. having slashes, 
except when of the form `./name'), FindFile()/DirLookup() first looks 
the final filename component in the cache for each directory on the search 
path and then proceeds to match the prefixed directory components by 
comparing them to the trailing directory components of the the search 
path being probed. 

This is not correct. When looking for `bar/target' in a path `.../src/foo', 
you want it to come up with `.../src/foo/bar/target' (if it exists). There's 
no point in comparing the the `bar' prefix on the target to the `foo' suffix 
on the search path. Indeed, this will cause a false match if those prefix 
and suffix components are actually equal and search path itself also has a 
file called `target'. For example, looking for `foo/target' in `.../src/foo' 
will spuriously match `.../src/foo/target', not `.../src/foo/foo/target'. 

This last bug prompted the change in dir.c, rev 1.27, which happens 
to partially workaround it by avoiding the above matching code in the 
case of the `curdir' search path entry (at the cost of incurring an  
exorbitant amount of cache misses). The situation is unchanged however,      
when processing other entries on the search path (e.g. those other than  
`dot' and `cur'). 
Responsible-Changed-From-To: bin-bug-people->toolchain-manager 
Responsible-Changed-By: gnats 
Responsible-Changed-When: Tue Feb 12 00:58:32 PST 2002 
Responsible-Changed-Why:  
There is now a "toolchain-manager" which is the proper default role 
account for handling problem reports in the toolchain category. 

>Unformatted:

Home	PR Database Search