Date: Wed, 4 Jul 2007 20:14:30 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Attilio Rao <attilio@freebsd.org>, Alfred Perlstein <alfred@freebsd.org>, arch@freebsd.org Subject: Re: Fine grain select locking. Message-ID: <20070704201124.Q88371@fledge.watson.org> In-Reply-To: <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> <20070704114914.M552@10.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Jul 2007, Jeff Roberson wrote: >> 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. Embedded has also gotten really weird lately :-). Embedded can now mean things like multi-core CPUs. I agree we need to maintain breadth, and there are quite a few people who build embedded products on FreeBSD who are hopefully keeping an eye on the direction and performance. I know Sam has observed in the recent past that we've seen quite a bit of instruction count bloat due to focusing on higher end hardware. On higher end hardware, instructions are relatively cheap compared to cache misses, so instruction count may go up less noticeably, especially if the added instructions reduce the cache miss rate. On lower end hardware, those extra instructions can be more prominent in performance results. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070704201124.Q88371>