Date: Wed, 28 Dec 2005 19:47:27 -0500 From: Martin Cracauer <cracauer@cons.org> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-hackers@freebsd.org, Martin Cracauer <cracauer@cons.org> Subject: Re: My wish list for 6.1 Message-ID: <20051228194727.B83703@cons.org> In-Reply-To: <43ACACFB.9070308@obsecurity.org>; from kris@obsecurity.org on Sat, Dec 24, 2005 at 12:35:47PM %2B1030 References: <43A26FFB.9080405@samsco.org> <20051216104022.A20877@cons.org> <20051217063409.GB19094@silverwraith.com> <20051217080109.GA31849@xor.obsecurity.org> <20051222173308.B23728@cons.org> <43ACACFB.9070308@obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote on Sat, Dec 24, 2005 at 12:35:47PM +1030: > Martin Cracauer wrote: > > > > > I tried to model different worklods. The parallel part of my > > benchmark suite has CPU-heavy processes, short plain http, php, long > > plain http and mixtures thereof. > > > > None of these showed the SMP kernel to be an overall disadvantage on a > > one-processor system. > > What you want is to find a real-world workload that exercises a lot of > mutexes. These exist, and they'll see the most pessimization from > running SMP kernel on UP. Well, I would be thankful for some ideas. I'd like to develop my benchmark suite from a pure hardware testing platform into one which can be used to measure improvements in SMP kernels. However, I am fully aware that what I am doing now (CPU loaders, and small and big http over localhost, make -j <x>) doesn't cut it. If you want to keep hardware out of the loop, things become hairy. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051228194727.B83703>