Date: Mon, 31 Mar 2003 10:56:23 +0300 From: Ruslan Ermilov <ru@freebsd.org> To: Bruce Evans <bde@zeta.org.au> Cc: "M. Warner Losh" <imp@bsdimp.com> Subject: Re: depend + all vs dependall Message-ID: <20030331075623.GA82512@sunbay.com> In-Reply-To: <20030331165732.Q17731@gamplex.bde.org> References: <20030329.163343.53040416.imp@bsdimp.com> <20030331042628.GA65700@sunbay.com> <20030331165732.Q17731@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Mon, Mar 31, 2003 at 05:04:42PM +1000, Bruce Evans wrote:
> On Mon, 31 Mar 2003, Ruslan Ermilov wrote:
>
> > On Sat, Mar 29, 2003 at 04:33:43PM -0700, M. Warner Losh wrote:
> > ...
> > > @@ -67,7 +67,7 @@
> > >
> > >
> > > .for __target in all all-man checkdpadd clean cleandepend cleandir \
> > > - depend distribute lint maninstall \
> > > + depend dependall distribute lint maninstall \
> > > obj objlink realinstall regress tags
> > > ${__target}: _SUBDIR
> > > .endfor
> >
> > If you want to really try dependall, you should implement it
> > in bsd.subdir.mk like the distribute target, similar to this:
> >
> > .if !target(dependall)
> > dependall:
> > cd ${.CURDIR}; \
> > ${MAKE} depend -DNO_SUBDIR; \
> > ${MAKE} all -DNO_SUBDIR
> > .endif
>
> That won't work, since it gives a double tree traversal for the
> subdirs and thus defeats the point of dependall. Any splitting
> up of dependall must not be passed down.
>
> > Also, your test is not honest because original Makefile.inc1
> > did not parallelize the "all" stage of "buildworld", by not
> > implementing par-all. Last time I tried par-all, it saved
> > me 16% of time from the -j8 buildworld:
> >
> > 26m8.74s real 26m13.08s user 11m9.70s sys (old)
> > 21m48.52s real 26m20.60s user 11m4.95s sys (new)
> >
> > Attached is the message with the patch. It has some Russian,
> > but also includes a patch. Note that par-all only parallelizes
> > top-level bsd.subdir.mk makefiles, as we depend on the ordering
> > of traversing SUBDIRs in a few places. The plan is to drop
> > this assumption in places that don't need this ordering.
>
> Please benchmark mainly for the usual case of non-SMP :-).
>
You mean for the non-SMP case but with -j?
On a Celeron 800 system with ATA100 disk using -j4 -DNOCLEAN buildworld
of RELENG_4 a friend reported the following times:
Without patch With patch
real 69m43.271s 69m26.722s
user 38m22.009s 38m19.384s
sys 10m45.273s 10m41.596s
Further reports show that on single-CPU systems with large CPU
cache the real time win was near what I have reported for 2-CPU
box, and it had no effect on small cache single-CPU systems and
-j builds.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
ru@sunbay.com Sunbay Software AG,
ru@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+h/SnUkv4P6juNwoRAncVAJ9s43OcueEcqlcyZcji1X+ghi6NvACfXw3E
ZIQ2HN9MoqBVvWBB8ym4LPI=
=749t
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030331075623.GA82512>