From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 19:04:04 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60DCE16A400; Wed, 4 Jul 2007 19:04:04 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3524C13C4AD; Wed, 4 Jul 2007 19:04:04 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l64J413h033261 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2007 15:04:02 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 4 Jul 2007 12:03:34 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Gary Palmer In-Reply-To: <20070704170522.GB53564@in-addr.com> Message-ID: <20070704114914.M552@10.0.0.1> References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> <20070704105525.GU45894@elvis.mu.org> <20070704124833.W37059@fledge.watson.org> <3bbf2fe10707040800p4e003df0p65e2b802f81ec51e@mail.gmail.com> <20070704174511.C67251@fledge.watson.org> <20070704170522.GB53564@in-addr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , arch@freebsd.org, Alfred Perlstein , Robert Watson Subject: Re: Fine grain select locking. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2007 19:04:04 -0000 On Wed, 4 Jul 2007, Gary Palmer wrote: > On Wed, Jul 04, 2007 at 05:46:34PM +0100, Robert Watson wrote: >> >> On Wed, 4 Jul 2007, Attilio Rao wrote: >> >>> 2007/7/4, Robert Watson : >>>> There seem to be two parts of owning a benchmark: >>>> >>>> - Establishing baselines over time -- how doe FreeBSD 4.8, 5.5, 6.0, 6.1, >>>> 6.2, >>>> 6-STABLE weekly, 7-CURRENT weekly, and maybe a Linux or NetBSD version >>>> perform for the workload using otherwise identical configuration. >>>> >>>> - Measurement and feedback -- identifying bottlenecks, working with >>>> developers >>>> to measure the results of specific optimizations, etc, across the life >>>> cycle >>>> of the patch. >>> >>> Another problem here would be about the hardware availabilty (obviously >>> I'm speaking about scalability improvements). Until now, tests have been >>> done mainly on amd64 machines provided by Kris and Jeff, IIRC. Having a >>> wider range of targets would help a lot in these cases. >> >> The FreeBSD Foundation is currently working on updating the Netperf test >> cluster from dual-cpu HTT boxes to 8-core systems, and from 1gbps to 10gbps >> ethernet. Hopefully this will improve access to larger multicore systems >> for developers without local hardware. This project has been "in progress" >> for a while now, but will wrap up soon. > > Hi Robert, > > Another way of looking at Attilio's message is that we need to focus on > more than one type of platform. In addition to benchmarking any differences > between large 8 core Opteron and Xeon systems and the Sun "CoolThreads" > platform, we need to maintain scalability on "more affordable" single > core hardware as well. An immediate thought is embedded type systems > such as the Soekris. While high-end server farms have always been our > bread and butter, I think widening our focus might be worthwhile. I might > have missed it, but I don't remember results being published to ensure > that while SMP systems gain performance that we don't adversely impact > UP systems in the process. (My memory is far from perfect, apologies if > I'm wrong) While I think it's very worthwhile to pick many different targets, I also think we need some sort of priority. My goal has been to optimize for 4-8 core performance for the 7.0 timeframe. We have generally made a lot of decisions to boost SMP performance at the cost of UP performance and I believe that will continue. The trends in processors are towards very affordable multicore packages and 7.0 will probably not be replaced until after 16core dual socket machines are not uncommon. The embedded space is obviously very important as well. However it's a competing optimization in some cases. Hopefully the developers working on embedded platforms can help us to find good compromises or ways to option out expensive things. Thanks, Jeff > > Regards, > > Gary > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >