From owner-freebsd-current@FreeBSD.ORG Tue Apr 1 23:29:26 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC29437B401 for ; Tue, 1 Apr 2003 23:29:26 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C6EB43F3F for ; Tue, 1 Apr 2003 23:29:26 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0093.cvx40-bradley.dialup.earthlink.net ([216.244.42.93] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 190cgT-0006cS-00; Tue, 01 Apr 2003 23:29:22 -0800 Message-ID: <3E8A9101.66FE4135@mindspring.com> Date: Tue, 01 Apr 2003 23:28:01 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: csujun@21cn.com References: <20030402070515.40396.qmail@web41803.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a44879d9401f18aea621888d9a2c7d0dba548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: current@FreeBSD.org Subject: Re: libthr and 1:1 threading. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 07:29:27 -0000 Jun Su wrote: > [ ... 1:1 kernel threads implementation ... ] > > A benchmark would be interested. This request doesn't make sense. The primary performance reasoning behind a 1:1 kernel threading implementation, relative to the user space single kernel entry scheduler in the libc_r implementation is SMP scalability for threaded applications. Basically, the only reasonable benchmark, given this, for a comparison of the two would be a threaded CPU-bound program on a *non-SMP* system. That really makes no sense, because that wasn't the use case for the design goal of SMP scalability; it doesn't really matter *what* the relative performance is on UP systems, relative to the libc_r library, so long as it adds SMP scalability. Which it does. It's apples and oranges; there's really no reasonable way to compare the two implementations, since they solve different problem sets. Could you maybe ask a different question? -- Terry