From owner-freebsd-arch@FreeBSD.ORG Sun Nov 26 18:09:31 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 01CF516A511 for ; Sun, 26 Nov 2006 18:09:31 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70199441DF for ; Sun, 26 Nov 2006 18:02:49 +0000 (GMT) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GoOKA-00004q-M2 for freebsd-arch@freebsd.org; Sun, 26 Nov 2006 19:01:54 +0100 Received: from 89-172-50-96.adsl.net.t-com.hr ([89.172.50.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Nov 2006 19:01:54 +0100 Received: from ivoras by 89-172-50-96.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Nov 2006 19:01:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Sun, 26 Nov 2006 19:01:44 +0100 Lines: 19 Message-ID: References: <20061119041421.I16763@delplex.bde.org> <20061126174041.V83346@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-50-96.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) In-Reply-To: <20061126174041.V83346@fledge.watson.org> Sender: news 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: Sun, 26 Nov 2006 18:09:31 -0000 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. > 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?