From owner-freebsd-arch@FreeBSD.ORG  Tue Oct 25 23:18:25 2005
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 613BD16A41F;
	Tue, 25 Oct 2005 23:18:24 +0000 (GMT)
	(envelope-from davidxu@freebsd.org)
Message-ID: <435EBD49.7090207@freebsd.org>
Date: Wed, 26 Oct 2005 07:18:33 +0800
From: David Xu <davidxu@freebsd.org>
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: Marc Olzheim <marcolz@stack.nl>
References: <Pine.GSO.4.43.0510241948130.17636-100000@sea.ntplx.net>	<20051025120538.K52058@fledge.watson.org>	<435E2DCF.6080809@freebsd.org>
	<20051025134834.GB62148@stack.nl>
In-Reply-To: <20051025134834.GB62148@stack.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Daniel Eischen <deischen@freebsd.org>, arch@freebsd.org,
	Robert Watson <rwatson@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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2005 23:18:25 -0000

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...)
>
>Marc
>  
>
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.

David Xu