From owner-freebsd-threads@FreeBSD.ORG Tue Jul 6 21:04:35 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FE2916A4CE for ; Tue, 6 Jul 2004 21:04:35 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F4B743D3F for ; Tue, 6 Jul 2004 21:04:35 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i66L4XqM020584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jul 2004 17:04:33 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i66L4R7F017816; Tue, 6 Jul 2004 17:04:27 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16619.5083.714960.598268@grasshopper.cs.duke.edu> Date: Tue, 6 Jul 2004 17:04:27 -0400 (EDT) To: Daniel Eischen In-Reply-To: References: <16619.3035.165728.569632@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: pthread switch (was Odd KSE panic) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2004 21:04:35 -0000 Daniel Eischen writes: > On Tue, 6 Jul 2004, Andrew Gallatin wrote: > > > > > Daniel Eischen writes: > > > Note that he is holding the mutex while calling pthread_cond_signal(). > > > If we enable preemption in pthread_cond_signal(), then I suspect it > > > would be even worse than without preemption. > > > > > > I think the only place where it is sane to enable preemption is > > > on pthread_mutex_unlock(). > > > > That certainly makes sense to me. But I don't want to see you > > optimize the threads lib just for my app. I can always put in an > > #ifdef FreeBSD > > pthread_yield() > > #endif > > > > But what I'm still wondering is where the ~3x slowdown (20usec linux > > -> ~60usec, libthr) is coming from. Is this a factor of the context > > switch time and ithreads? > > I suspect our kernel is butt-slow compared with Linux in general. > Mysql under native linux is similarly faster. The butt-slowness is why I always whine about performance :-( > > I need to move the driver to a fast interrupt and I need to test > > SCHED_BSD as well. I should probably cvs update to get jhb's > > scheduling changes. With jhb's preemption changes, SCHED_4BSD, machdep.cpu_idle_hlt=0, kern.threads.virtual_cpu=1, pthread_yield(), and a partridge in a pear tree, I can get it down to 48us with KSE. Best for libthr is now 57us. This is apples to oranges, because of the ULE/BSD and preemption changes. So I'll wait until ULE works before trying to see if the change was preemption.. Drew