From owner-freebsd-arch@FreeBSD.ORG Tue Nov 28 14:23:51 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8EA4716A407 for ; Tue, 28 Nov 2006 14:23:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 864CB43CA0 for ; Tue, 28 Nov 2006 14:23:48 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D0A4A46E24; Tue, 28 Nov 2006 09:23:50 -0500 (EST) Date: Tue, 28 Nov 2006 14:23:50 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: Message-ID: <20061128142218.P44465@fledge.watson.org> References: <20061119041421.I16763@delplex.bde.org> <20061126174041.V83346@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: What is the PREEMPTION option good for? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2006 14:23:51 -0000 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