From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 11:04:25 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E818B16A40F for ; Wed, 20 Sep 2006 11:04:25 +0000 (UTC) (envelope-from soralx@cydem.org) Received: from cydem.org (S0106000103ce4c9c.vc.shawcable.net [24.87.27.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5EDC43D4C for ; Wed, 20 Sep 2006 11:04:25 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from soralx.cydem.org (unknown [192.168.0.249]) by cydem.org (Postfix/FreeBSD) with ESMTP id 9E11890D55 for ; Wed, 20 Sep 2006 04:04:24 -0700 (PDT) From: soralx@cydem.org To: freebsd-hackers@freebsd.org Date: Wed, 20 Sep 2006 04:04:23 -0700 User-Agent: KMail/1.9.1 References: <200609141232.k8ECWTXj045191@lurza.secnetix.de> <20060919173421.GA45928@xor.obsecurity.org> <20060920123940.W63482@woozle.rinet.ru> In-Reply-To: <20060920123940.W63482@woozle.rinet.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200609200404.23618.soralx@cydem.org> Subject: Re: numbers don't lie ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2006 11:04:26 -0000 > KK> > My experiments show that if you have enough memory to host radmdrive for > KK> > /usr/src you'd better leave it for caching - there were no statistically > KK> > meaningful performance difference, at least on machines with 1G+ RAM. > KK> > KK> Really? My measurements show the opposite (on a system with 16GB of > KK> RAM). > > My last test on amd64/dualcore with 4G of RAM and -j4 shows > (buildworld+buildkernel): > > ==> /tmp/buildlog <== > 1996.45 real 3032.94 user 624.83 sys > Script done on Tue Sep 19 14:44:54 2006 > > ==> /tmp/buildlog.md <== > 1957.45 real 3033.93 user 585.78 sys > Script done on Tue Sep 19 15:20:42 2006 > > Second one was with 512M/4k/512 swap-backed md, the former with /usr/src on the > gmirror'ed pair of SATAs. In both cases, the amount of processing was the same ('user' times are remarkably close to each other: ~3033.5 CPU-seconds), because the source code didn't change. However, in the first case additional 39 seconds were spent in kernel ('sys'), which made the whole compile process be 39 seconds slower in real time. Notice how {(3033.93/2)+585.78=2102.745} > {1957.45}. Where had those 'extra' 145.3 seconds gone? 2 possibilities: 0a. The number of cores is not 2, but 2.21 rather, meaning that each core is loaded 110.6% (i.e., each CPU-second of computations takes noticeably less than 1 second of real time to complete, assuming 100% load). This is impossible. Changes in user time should always track changes in real time. 0b. 'Sys' time calculation might not be totally independent of 'user' time. So, I say if 0a is somehow true, then the setup is likely CPU-bound, but if 0b is true, then it's probbly IO-ound. Well, I suppose it's hitting both limits at times, as swapping seems to be present too. My logic could be broken here, though, 'cause it's 04:00 in the morning... > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [SorAlx] ridin' VN1500-B2