From owner-freebsd-arch@FreeBSD.ORG Tue Oct 25 14:45:43 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 8550216A41F; Tue, 25 Oct 2005 14:45:43 +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 3063C43D4C; Tue, 25 Oct 2005 14:45:43 +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 D484546B03; Tue, 25 Oct 2005 10:45:42 -0400 (EDT) Date: Tue, 25 Oct 2005 15:45:42 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Marc Olzheim In-Reply-To: <20051025134834.GB62148@stack.nl> Message-ID: <20051025153950.S31152@fledge.watson.org> References: <20051025120538.K52058@fledge.watson.org> <435E2DCF.6080809@freebsd.org> <20051025134834.GB62148@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@freebsd.org, David Xu 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: Tue, 25 Oct 2005 14:45:43 -0000 On Tue, 25 Oct 2005, Marc Olzheim wrote: >> libc_r runs on single kernel thread, so if you are continue using >> libc_r, you are not testing TCP/IP with multithreads program, this may >> give you false data. Only kernel threads based server can test to see >> if the TCP/IP stack locking works well. > > Erhm, its not about testing the TCP/IP stack locking, this is about > stable and raw performance. Of course the single kernel thread might > have a negative impact on total performance, but in our real world > applications, I don't see a real performance boost from KSE. > > What I do see is easier and cleaner programming with KSE, but once > you've done all the work to get usable libc_r based I/O, it works good. > (Well, unless you need to fork+exec from a heavily mallocing thread > system, without a patch similar to the one in PR threads/76690...) The change in performance from threading libraries varies for me a great deal by workload. I found that with MySQL, I did see significant improvements from switching to non-libc_r threading models, as the task was no longer blocked on synchronous I/O to disk. However, the results I posted in an earlier message illustrate a workload without synchronous blocking I/O, due to using sendfile() on a small set of files that basically live in the buffer cache. I've seen several workloads where using SMP improves performance, but in the test I posted earlier, SMP runs slower than UP, probably due to the fact that it's basically a test over overhead costs for context switch, system calls, and access to process data structures (such as file descriptors), so there's lots of room for overhead. I assume that the varying relative costs for libthr/libpthread/libc_r shed some light on things like the relative costs of system calls and context switches, as well as the degree to which the user and kernel schedulers can make effective use of available CPU resources. Robert N M Watson