From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 12:11:59 2004 Return-Path: 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 B5ECD16A4CE; Fri, 12 Nov 2004 12:11:59 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17DE243D2F; Fri, 12 Nov 2004 12:11:59 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iACCBuCJ097257; Fri, 12 Nov 2004 13:11:57 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Ruslan Ermilov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 12 Nov 2004 13:58:24 +0200." <20041112115824.GA85834@ip.net.ua> Date: Fri, 12 Nov 2004 13:11:56 +0100 Message-ID: <97256.1100261516@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: Harti Brandt cc: current@freebsd.org Subject: Re: [TEST] make -j patch [take 2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 12 Nov 2004 12:11:59 -0000 In message <20041112115824.GA85834@ip.net.ua>, Ruslan Ermilov writes: >> >> that is a long running regression test that I don't want to occupy my= >=20 >> >> 4 processor machine, but I want the tool for the test to build fast. >> >>=20 >> >Here's the patch that changes the -j behavior the way I want it: >>=20 >> I think that patch is a bad idea. >>=20 >Care to explain? I have explained this several times already: You should just leave the submakes on their own and let them balance as they see fit. I spent a lot of time on parallel/clustered make for a customer and the outcome of that is very clear: Leave the stuff alone after you have said your overall intention. Obviously you are not going to trust me on this, since you seem to have very strong ideas on how you think it works in practice, even though you don't seem to have any actual data to back it up with. I suggest that you actually try out your ideas in _practice_, not just with a few "proof of concept" makefiles made for the purpuse, but try to actually _run_ it on real world jobs for some weeks while you carefully gater statistics and examine the interactions between the parameters given, where given, resulting time to build and loading of the machine(s). At the very least, do not commit your patch until you have managed to come up with at least one instance of real world data where it is a good idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.