From owner-freebsd-threads@FreeBSD.ORG Thu Oct 7 23:52: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 163C316A4DC for ; Thu, 7 Oct 2004 23:52:35 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB44A43D41 for ; Thu, 7 Oct 2004 23:52:34 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) i97NqYmU002655; Thu, 7 Oct 2004 19:52:34 -0400 (EDT) Date: Thu, 7 Oct 2004 19:52:34 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Pawel Worach In-Reply-To: <4165C285.9050909@telia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-threads@freebsd.org Subject: Re: BIND9 and libpthread performance X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2004 23:52:35 -0000 On Fri, 8 Oct 2004, Pawel Worach wrote: > Hi, > > I did some simple benchmarking with libpthread vs. libc_r and BIND. > The numbers puzzle me. Are pthreads supposed to this much slower? > > Tests done using BIND9 with a authoritative root zone. The queryperf > tool from bind-9.3.0/contrib/queryperf was used to get the numbers. > Queries where done for ". SOA". (queryperf -s 127.0.0.1 -l 30) > > This is on -CURRENT from Oct 6th, WITNESS, INVARIANTS off and > libpthread built without _LOCK_DEBUG and _PTHREADS_INVARIANTS. > Hardware is a dual IBM x345 2.8ghz Xeon box with HTT on. SCHED_4BSD, > PREEMPTION and ADAPTIVE_GIANT are in the kernel config, malloc.conf > symlinked to 'aj'. So that's a true dual CPU system with HTT CPUs (the kernel sees 4 CPUs)? Turn HTT off, set kern.threads.virtual_cpu = 1, and try using process scope threads. Then set kern.threads.virtual_cpu = 2 and try again using process scope threads. Then try the same 2 tests with system scope threads. You can set LIBPTHREAD_SYSTEM_SCOPE in your environment to force system scope threads, and set LIBPTHREAD_PROCESS_SCOPE to force process scope threads (you needn't rebuild libpthread or your application). If they are both set, system scope wins out. -- Dan Eischen