Date: Fri, 29 Sep 2006 14:04:55 -0500 From: Astrodog <astrodog@gmail.com> To: "Ruslan Ermilov" <ru@freebsd.org> Cc: rwatson@freebsd.org, current@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: lockf in installworld -- not a good idea Message-ID: <2fd864e0609291204gf8209e0i5b7975af7b780623@mail.gmail.com> In-Reply-To: <20060929182053.GG37741@rambler-co.ru> References: <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> <20060929.091414.74722768.imp@bsdimp.com> <20060929172657.Q74256@fledge.watson.org> <20060929.110942.1723237142.imp@bsdimp.com> <20060929182053.GG37741@rambler-co.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/29/06, Ruslan Ermilov <ru@freebsd.org> wrote: > > On Fri, Sep 29, 2006 at 11:09:42AM -0600, M. Warner Losh wrote: > [...] > > I tend to agree with that basic philosophy. From other items in the > > thread, it was clear this came up in the context of build release, > > which benefits from -j usually. The installworld phase in that should > > be as robust as possible as well, since otherwise we have issues with > > the actual release. Unless it is a big win (more than a few percent), > > I'd imagine the right fix is to the release target to not do a > > parallel installworld. I know that in the build scripts that I wrote > > in 3.x days and have ported forward since then I've never done a > > parallel install, due to it rarely working reliably in that (long) > > time span... > > > They are safe to do nowadays. I'll do some measurements on real > SMP with the memory-based DESTDIR, and let you know the numbers. I'd be interested in non-memory-based DESTDIR, too, since there's certainly the possibility, for install, to slow things down with -j because of additional HDD seeks and such. Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2fd864e0609291204gf8209e0i5b7975af7b780623>