From owner-freebsd-ppc@FreeBSD.ORG Wed Jun 4 08:10:55 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C0F267C; Wed, 4 Jun 2014 08:10:55 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CBE123EB; Wed, 4 Jun 2014 08:10:54 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id mc6so4129881lab.2 for ; Wed, 04 Jun 2014 01:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1OFKJg4soMskovDB7JcoKfPd2SJ28+1fAvlPuuISBuI=; b=OpVi0SABGyZec62uKsWAOhdMG4pXoB+woEeOGbdezZHbGNNHEtobHwbWmfTtltDwiB I+zth2vviYgk7jg0WE8C0cxgdjgjryiu8ae/0QvsfPP8QIKGGrime8nGkFxNK0SfNCgV Fuhv0KMd4wag98A5AVcWtrI4UVV8lXHmBcurhaSQNuTh25wWSGpMrSCRnoec6enm263j NB5w9gq8oCjKEQcN+NZgy8ixTYOGK1dTzlJbwy8d2lk7pAwIZKARHLlnTVCQZh/eLzn8 KeO2ffBGVZP0yuXjV0su2jqnrIvKCFX7w0pFHdSE4ysGgnNZXfZQCwf9Ofw3ve/0wXwK IxPg== X-Received: by 10.152.6.131 with SMTP id b3mr39340116laa.9.1401869452483; Wed, 04 Jun 2014 01:10:52 -0700 (PDT) Received: from [192.168.1.197] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by mx.google.com with ESMTPSA id x2sm1472996lae.1.2014.06.04.01.10.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 01:10:51 -0700 (PDT) Message-ID: <538ED489.1000307@gmail.com> Date: Wed, 04 Jun 2014 11:10:49 +0300 From: Jukka Ukkonen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alexey Dokuchaev Subject: Re: Odd failures during parallel PPC builds References: <5388B184.4050309@freebsd.org> <538992B4.8030209@gmail.com> <20140603021026.GD60685@FreeBSD.org> In-Reply-To: <20140603021026.GD60685@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@FreeBSD.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 08:10:55 -0000 On 2014-06-03 5:10, Alexey Dokuchaev wrote: > On Sat, May 31, 2014 at 11:28:36AM +0300, Jukka Ukkonen wrote: >> Now it seems I have found something going wrong with >> parallel make on ppc such that the same symptoms cannot >> be reproduced on an amd64 platform. >> >> [...] >> >> Is there anyone else trying to run local builds on >> 32-bit ppc? If so, have you noticed any problems with >> parallel make? Is there any other way to work around >> this problem but avoiding the parallel builds completely? > I normally do not build in parallel since it makes no sense on my single > CPU Mac mini G4, but I can loop buildworld with some -jX value to see if > I can catch anything. > > ./danfe It seems that almost every process waits for disk on occasion just to read in the compiled file and header files at least. So, having a few compiler processes active at the same time usually makes sense because another compilation can proceed while one ends up waiting for the disk. When the compiled files are small and the compilation does not require a lot of memory as is often the case with C library functions etc. the number of parallel jobs can obviously be a bit larger. I have typically used some 4-6 jobs per CPU on PowerPC when the memory load per compilation unit is relatively low. When compiling large C++ files the number of jobs has to be kept low to avoid pointless paging on a system with limited physical memory. Anyhow building serially 1 job at a time or using always one job per CPU are not necessarily the optimal choices. The optimum depends on the amount of memory, the speed of the memory, and the speed of the disk(s). My personal approach has been trying to keep the CPUs as busy as possible while avoiding paging and having /usr/src and /usr/obj on separate disks such that each disk sits on its own storage bus. The time difference in building the full OS can be hours in some cases. --jau