From owner-freebsd-arch@FreeBSD.ORG Thu Oct 27 01:05:31 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9F01A16A41F; Thu, 27 Oct 2005 01:05:30 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <436027E6.8080604@freebsd.org> Date: Thu, 27 Oct 2005 09:05:42 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20051025120538.K52058@fledge.watson.org> <435E2DCF.6080809@freebsd.org> <20051025134834.GB62148@stack.nl> <435EBD49.7090207@freebsd.org> <20051026120219.V32255@fledge.watson.org> In-Reply-To: <20051026120219.V32255@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marc Olzheim , Daniel Eischen , arch@freebsd.org Subject: Re: libc_r is deprecated 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: Thu, 27 Oct 2005 01:05:32 -0000 Robert Watson wrote: > ... > I'll try to set up and run Apache2 with various configurations as a > substitute for the performance measurement httpd I have in > src/tools/tools/netrate, and see how its mpms interact with our > threading implementations. > > My increasing suspicion is that the performance issue for threads is > heavy access to the file descriptor related locks, resulting in > significant contention. I need to look at traces and profiling some > more to decide which are the biggest problems, and whether there are > useful ways to improve them that help. In the libthr vs. libpthread > measurements, it could well be that libpthread reduces kernel lock > contention by allowing a thread to compete less with itself for locks: > i.e., it introduces additional kernel threads only when blocked on a > real sleep, not a mutex wait, whereas with libthr, threads will yield > to each other on a CPU as they sleep on mutexes, resulting in more > mutex contention. This is just a conjecture, however. > You sample program is nothing to do with libpthread or libthr, you never have userland locking code, in kernel they should be same, in fact. I have done a simple test, on my dual PIII machine, libthr is faster than libpthread, if I use ULE, libpthread is far behind than libthr, I recommend you to try different file sizes, I have got very different result, for small file size, e.g /usr/src/sys/sys/umtx.h, libthr beats libpthread, I can not test big file, because my 100M network is very easy to be saturated. If you suspect fd locking overhead, try to use fork() model, though it will introduce more context switch overhead, but it still worthy to do. > Robert N M Watson