From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 17:12:16 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7297516A40F; Fri, 29 Sep 2006 17:12:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7038B43D73; Fri, 29 Sep 2006 17:12:05 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k8THAbwH028380; Fri, 29 Sep 2006 11:10:37 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 29 Sep 2006 11:09:42 -0600 (MDT) Message-Id: <20060929.110942.1723237142.imp@bsdimp.com> To: rwatson@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20060929172657.Q74256@fledge.watson.org> References: <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> <20060929.091414.74722768.imp@bsdimp.com> <20060929172657.Q74256@fledge.watson.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 29 Sep 2006 11:10:38 -0600 (MDT) Cc: astrodog@gmail.com, current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 17:12:16 -0000 In message: <20060929172657.Q74256@fledge.watson.org> Robert Watson writes: : : On Fri, 29 Sep 2006, Warner Losh wrote: : : >> For what its worth.... I'd go with just stopping support for -j in : >> installworld, even if things are CPU bound. : > : > installworld should *NEVER* be done -j. Ever. That wasn't part of the : > installworld bargin when it was started. There's no point to it at all. : > As such, any support to make it work should be removed with extreme : > prejustice. Why on earth would you want to do installworld -j? : : I wouldn't doubt that it's at least marginally faster, possibly a : bit faster, but I think I come down pretty firmly on the side of : "let's make installworld as simple and reliable as possible" -- : breaking in the middle of installworld can have messy consequences, : and we should minimize the chances of that as much as possible. 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... Warner