From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 00:46:49 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 223E5106566B for ; Tue, 3 Feb 2009 00:46:49 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id DB18A8FC13 for ; Tue, 3 Feb 2009 00:46:48 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n130kgDi015506; Mon, 2 Feb 2009 16:46:42 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n130kgqB015505; Mon, 2 Feb 2009 16:46:42 -0800 (PST) (envelope-from obrien) Date: Mon, 2 Feb 2009 16:46:42 -0800 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20090203004642.GC14870@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "M. Warner Losh" , arch@FreeBSD.org References: <20090130.085130.-4349483.imp@bsdimp.com> <20090130.093052.-2022808221.imp@bsdimp.com> <20090202220628.GA76833@dragon.NUXI.org> <20090202.154213.387237162.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090202.154213.387237162.imp@bsdimp.com> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 00:46:49 -0000 On Mon, Feb 02, 2009 at 03:42:13PM -0700, M. Warner Losh wrote: > Two points here. > (1) Should this be opt-in or opt-out. Is the output really so useful > that we can't live without it? I think it should be -v to get the > output. This is referred to as 'a -Q world' vs 'a -v world' in > other discussions, so I'll use that here. What is the use-case > that shows it is a win to be opt-in? What does having it on > always buy us that having to repeat a run of a build with special > debugging args to debug a problem fail to achieve? It can be hard to get users to repeat something as-is. Enabling the job markers by default gives the information needed to understand issues is present. Much like Robert Watson's desire for textdumps - you want enough information to understand the problem when it occurred. Its hard to get users to go back and get the needed information. Maybe I'm the only one that has found it hard to pin point the reason for a build break with 'make -j'; but I do know over the years we've told folks that report build breaks while using 'make -j' to do the build again with no -j - one reason being its hard to figure out what happened in the build. As if, the way to get support is ``make -j8 buildworld || make buildworld'' > : I've tried to measure the "~10% performance improvement" in using > : 'make -s' that was the technical justification for r187921. I have > : been unable to achieve ~10%. The summary is: > > [[ benchmarks deleted showing about a 2-3% drop in performance for -s ]] > I was careful to caveat that with some environments. The one I was > in was NFS to a slow server on an otherwise fast machine. Actually the commit message said "many environments", but I think we've both added more details and folks can investigate for their own environment. > I think the > output size arguments are weak at best since they don't take into > account the semantic value added by the output. Sure, disks can > handle it, but does it add value for people or scripts reading the > output? However, I think that it is a moot point since (a) I've back > out the change and (b) the output is currently wrong. Once (b) is fixed, I do think it adds value for people and some scripts reading the output. Scripts can unwind the output and present the complete part of the build for a particular target. -- -- David (obrien@FreeBSD.org)