Date: Tue, 28 Nov 2006 14:23:50 +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: <20061128142218.P44465@fledge.watson.org> In-Reply-To: <ekckpt$4h6$1@sea.gmane.org> References: <20061119041421.I16763@delplex.bde.org> <ejnvfo$tv2$1@sea.gmane.org> <ek4gc8$492$1@sea.gmane.org> <20061126174041.V83346@fledge.watson.org> <ekckpt$4h6$1@sea.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 26 Nov 2006, Ivan Voras wrote: > Robert Watson wrote: > >> 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. > > The dynamic stuff is accessing the database (fairly intensively) over the > loopback. This may be significantly affected by preemption then. >> 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. > > Try this with or without PREEMPTION? They're independent twiddles, and can be frobbed separately. If you can easily measure performance in the different configurations, seeing a table of permutations and results would be very nice to see what happens :-). 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?20061128142218.P44465>