From owner-cvs-all@FreeBSD.ORG Thu Jun 2 12:23:07 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 205F616A41C; Thu, 2 Jun 2005 12:23:07 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A6B443D1F; Thu, 2 Jun 2005 12:23:06 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.95] (2-zyx-piter-f0285.r5.ll.kw.ua [195.140.246.50]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j52CMpIV050887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2005 14:22:54 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <429EFA1A.1050503@portaone.com> Date: Thu, 02 Jun 2005 15:22:50 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <200506011552.j51FqdR2046893@repoman.freebsd.org> <429DED77.9050003@samsco.org> <429DF37B.8010203@portaone.com> <429DF38B.2020107@samsco.org> <429DF9E9.9060307@portaone.com> <867jhdnj2o.fsf@xps.des.no> In-Reply-To: <867jhdnj2o.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/906/Wed Jun 1 23:38:56 2005 on www.portaone.com X-Virus-Status: Clean Cc: cvs-src@FreeBSD.org, Scott Long , Tim Kientzle , cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/lib/libarchive archive_private.h archive_read.c archive_read_data_into_fd.c archive_write.c archive_write_set_compression_bzip2.c archive_write_set_compression_gzip.c archive_write_set_compression_none.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim.Sobolev@portaone.com List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2005 12:23:07 -0000 Dag-Erling Smørgrav wrote: > Maxim Sobolev writes: > >>Therefore, IMHO, the only realistical approach is to improve >>tinderboxes to minimize detection window (i.e. faster, multi-CPU >>hardware and/or tools like ccache) and to make breakage information >>delivery more direct. > > > Faster, multi-CPU hardware will not help. The tinderbox is > constrained by memory bandwidth, not CPU speed. A cluster of seven > $200 Mini-ITX boxes can do a full -CURRENT tinderbox run in two or > three hours, vs. eight to ten hours on a single $1400 box. > > Ccache won't help either, because buildworld always starts by building > a new toolchain, which invalidates the cache. Yes, but ccache can be easily extended to make it useable for buildworlds. Currently it uses path to, last modification time of (and probably size of) the compiler binary to decide validity of existing cache, which is not very intelligent check. I've verified that albeit they have different modification times (obviously), every buildworld produces compiler binaries with the same MD5 checksum. Therefore ccache can be extended to keep table with four values {path, modtime, size, MD5} for each compiler binary, so that it can lookup the MD5 checksum based on path, modtime and size of compiler binary and the use that MD5 for deciding upon validity of the cache. -Maxim