svn commit: r359685 - in head: . etc lib/libc/gen share/mk share/termcap usr.bin/login usr.bin/vgrind usr.sbin/services_mkdb

Rodney W. Grimes freebsd at gndrsh.dnsmgr.net
Fri Apr 10 17:43:29 UTC 2020


> On 4/7/2020 3:37 AM, Rodney W. Grimes wrote:
> >> Author: sobomax
> >> Date: Tue Apr  7 02:46:22 2020
> >> New Revision: 359685
> >> URL: https://svnweb.freebsd.org/changeset/base/359685
> >>
> >> Log:
> >>   Normalize deployment tools usage and definitions by putting into one place
> >>   instead of sprinkling them out over many disjoint files. This is a follow-up
> >>   to achieve the same goal in an incomplete rev.348521.
> > I have concerns that this factoring out of 5 values that have not changed
> > in 25 years is a pessimization, it is one more file that make has to
> > open on each invocation.
> > 
> > 
> 
> The truth is that this additional file read is on top of hundreds of new
> reads per directory in the past few years. It can suck on NFS but
> otherwise this 1 change is very minor compared to other additions. One
> big example is foo.o.depend for each foo.o. Or bmake doing
> realpath(getcwd()) on every invocation. Improving those, or the bmake
> job queue, or bmake's overuse of /bin/sh, would go a lot further than
> the hit from this commit.

True, it was unfair of me to pick on this one change, there are a long
slow gradual increase in the disk I/O intensity of buildworld over
time.  I was more raising that general issue, that we should keep
an eye towards that as we make changes to the build system, we should
be very careful of anything that pessimizes the build.

My concerns are for people, like mdexter, that run Build Option
Serveys, which is basically 240 buildwords in a single invocation
with run times on the order days to complete, or for CI clusters
doing 1000's of builds a week.

> -- 
> Regards,
> Bryan Drewery
-- 
Rod Grimes                                                 rgrimes at freebsd.org


More information about the svn-src-head mailing list