Date: Sun, 26 Nov 2006 17:44:20 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Ivan Voras <ivoras@fer.hr> Cc: freebsd-arch@freebsd.org Subject: Re: What is the PREEMPTION option good for? Message-ID: <20061126174041.V83346@fledge.watson.org> In-Reply-To: <ek4gc8$492$1@sea.gmane.org> References: <20061119041421.I16763@delplex.bde.org> <ejnvfo$tv2$1@sea.gmane.org> <ek4gc8$492$1@sea.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 23 Nov 2006, Ivan Voras wrote: > Ivan Voras wrote: >> Bruce Evans wrote: >> >>> Most of the difference is caused by pgzero becoming too active with >>> PREEMPTION. >> >> Don't know about the other things but I've noticed pagezero is suspiciously >> active on heavy loaded SMP web servers (even complained on @stable a long >> time ago). I'll try disabling PREEMPTION and see how it goes. > > Ok, I couldn't run extensive tests because people were waiting to use the > machine, so this should be considered anecdotal evidence. On a simple > benchmark that repeatedly (for 1 minute) and concurrently (target=50 > concurrent requests) hits a dynamic web page on a development machine (2 > proc true SMP), the performance goes up from ~85 requests/sec. to ~105 > requests/s by disabling PREEMPTION. This improvement looks suspiciously high > to me, but I don't think I'll be going back :) pagezero is now not noticable > in 'top' output. There's a known performance regression with PREEMPTION and loopback network traffic on UP or UP-like systems due to a poor series of context switches occuring in the network stack. If your benchmark involves the above web load over the loopback, that could be the source of what you're seeing. If it's not loopback traffic, then that's not the source of the problem. You might try fiddling with kern.sched.ipiwakeup.enabled and see what the effect is, btw -- this controls whether or not the scheduler wakes up another idle CPU to run a thread when waking up that thread, rather than queuing it to run which may occur on the other CPU at the next clock tick. 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?20061126174041.V83346>