Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Jul 2007 12:03:34 -0700 (PDT)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        Gary Palmer <gpalmer@freebsd.org>
Cc:        Attilio Rao <attilio@freebsd.org>, arch@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, Robert Watson <rwatson@freebsd.org>
Subject:   Re: Fine grain select locking.
Message-ID:  <20070704114914.M552@10.0.0.1>
In-Reply-To: <20070704170522.GB53564@in-addr.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <rwatson@freebsd.org>:
>>>> 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"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070704114914.M552>