From owner-freebsd-arch@FreeBSD.ORG Wed Oct 26 11:08:30 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64CAC16A41F; Wed, 26 Oct 2005 11:08:30 +0000 (GMT) (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 10C9943D48; Wed, 26 Oct 2005 11:08:30 +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 DA17D46B45; Wed, 26 Oct 2005 07:08:26 -0400 (EDT) Date: Wed, 26 Oct 2005 12:08:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: David Xu In-Reply-To: <435EBD49.7090207@freebsd.org> Message-ID: <20051026120219.V32255@fledge.watson.org> References: <20051025120538.K52058@fledge.watson.org> <435E2DCF.6080809@freebsd.org> <20051025134834.GB62148@stack.nl> <435EBD49.7090207@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Wed, 26 Oct 2005 11:08:30 -0000 On Wed, 26 Oct 2005, David Xu wrote: > What is raw performance? are you comparing it with RELENG-4, if you only > need a single thread, why should we start SMP project ? I am interesting > to see libthr is worse than libc_r in real world application, give us > example. I have an example, run Dave's crew example from his book, > libc_r just falls on its face. > http://people.freebsd.org/~davidxu/ptest.tgz also, Robert can get better > result if he does not use libc_r but use a state machine but not thread > to serve http request like an example in ACE. We both know that many things can be made faster by not using threading, but apparently that isn't deterrence to prevent people from using threads when in fact it hurts performance :-). Our goals are presumably to: - Provide improved programming tools and models so that people can write better/faster code. For example, adding KQueue, etc. - Make the commonly used programming tools and models as fast as we can. Just because people use threads where it doesn't always make sense doesn't mean we shouldn't try to make their applications faster. Threads are widely used not just because they offer parallelism, but also because they offer a programming model that is appealing. 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. Robert N M Watson