Skip site navigation (1)Skip section navigation (2)
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>