From owner-freebsd-current@FreeBSD.ORG Thu Feb 14 10:36:36 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BD2416A468 for ; Thu, 14 Feb 2008 10:36:36 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE4013C447; Thu, 14 Feb 2008 10:36:34 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47B419B1.1010002@FreeBSD.org> Date: Thu, 14 Feb 2008 11:36:33 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Julian Elischer References: <20080213073155.GA1340@hoeg.nl> <20080213090842.65b240e6.wmoran@potentialtech.com> <47B3ED30.2040404@elischer.org> In-Reply-To: <47B3ED30.2040404@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Ian FREISLICH , Bill Moran , Ed Schouten Subject: Re: Testing box available. 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: Thu, 14 Feb 2008 10:36:36 -0000 Julian Elischer wrote: > my memory is that ohk changed make to have a fifo with N (as in -j N) > tokens in it and all child makes inherrit this fifo > (or get it's name from an environment variable or something) > and can only spawn extra makes if they can get a token. > When they have finished their work they pu the token back into the > fifo.. > > My memories of this may be somewhat inaccurate however. I think this is correct but it only helps to some extent. Large parts of the buildworld have no or low parallelism still (e.g. the whole 'make depend' phase). 'make buildworld' is not a good choice for testing parallelism. Running a "useful workload" is more interesting :) One of three things will happen: 1) It may scale well to 16 CPUs. 2) The scheduler may limit performance if your workload depends heavily on CPU locality. This is the case with the Intel 16-core system we have been using. The scheduler needs to gain knowledge of the CPU core topology in order to avoid making bad decisions about migrating processes between CPU cores that are far apart. Jeff is working on this. 3) Your workload may not scale because of a limiting factor in userland or in the kernel. If this is a limitation in FreeBSD and not the application then it is interesting. Actually it would be interesting to repeat some of our "standard tests" on the barcelona system to see how it compares to the intel one. Kris