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:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.