Date: Thu, 22 Dec 2005 17:33:08 -0500 From: Martin Cracauer <cracauer@cons.org> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-hackers@freebsd.org Subject: Re: My wish list for 6.1 Message-ID: <20051222173308.B23728@cons.org> In-Reply-To: <20051217080109.GA31849@xor.obsecurity.org>; from kris@obsecurity.org on Sat, Dec 17, 2005 at 03:01:09AM -0500 References: <43A26FFB.9080405@samsco.org> <20051216104022.A20877@cons.org> <20051217063409.GB19094@silverwraith.com> <20051217080109.GA31849@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote on Sat, Dec 17, 2005 at 03:01:09AM -0500: > On Fri, Dec 16, 2005 at 10:34:09PM -0800, Avleen Vig wrote: > > On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: > > > > 2. SMP kernels for install. Right now we only install a UP kernel, for > > > > performance reasons. We should be able to package both a UP and SMP > > > > kernel into the release bits, and have sysinstall install both. It > > > > should also select the correct one for the target system and make that > > > > the default on boot. > > > > > > If people are concerned about performance, I benchmarked a 6-beta > > > kernel SMP versus UP on a socket 939 Opteron. > > > > If those results are accurate, there's no real reason not to just use an > > SMP kernel on default install? > > Just because it didn't manifest on this workload, doesn't mean it > doesn't on others. I think this is the point :) 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. However, the tradeoffs are different. The SMP kernel further increases the tendency that FreeBSD had all along to give CPU eaters more resources, disk and network I/O less, compared to Linux. Whether this is good or bad is open for discussion. From a traffic control standpoint you can both argue that it is better to get the CPU demands out of the way instead of getting more I/O done only to have the I/Oing processes then pile up in the already overcrowded CPU-demanding corner - and you can argue that you should get I/O done ASAP so that the I/O-initiating process doesn't hang around neccessaryily long. This is for both schedulers. I don't think this tendency is directly caused by the scheduler, it is probably the I/O subsystems coercing the scheduler, not the other way round. 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?20051222173308.B23728>