Re: Fine grain select locking.

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@xxxxxxxxxxx>:
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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"