From owner-freebsd-arch Sun Sep 22 20:42:18 2002 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 7826537B401 for ; Sun, 22 Sep 2002 20:42:16 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 168D343E42 for ; Sun, 22 Sep 2002 20:42:12 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0439.cvx22-bradley.dialup.earthlink.net ([209.179.199.184] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17tK6d-0007kd-00; Sun, 22 Sep 2002 20:41:56 -0700 Message-ID: <3D8E8A99.CED8BAD0@mindspring.com> Date: Sun, 22 Sep 2002 20:29:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Bill Huey (Hui)" Cc: Daniel Eischen , freebsd-arch@FreeBSD.ORG Subject: Re: New Linux threading model References: <3D8B62DB.C27B7E07@mindspring.com> <20020923014729.GA3362@gnuppy.monkey.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Bill Huey (Hui)" wrote: > On Fri, Sep 20, 2002 at 11:03:07AM -0700, Terry Lambert wrote: > > By going to 1:1, they dodge this issue; but in so doing, they > > increase threads overhead to that of processes: threads become > > a mechanism for sharing some resources: the moral equivalent of > > the old rfork()/sfork() system calls for heap and descriptor > > space sharing, with seperate stacks. > > Conceptually this is definitely the case, but this says otherwise > for the particular operations they outline in this email: > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.2/1581.html > > Not sure what to think about this... The first set were the microbenchmarks I was talking about being unrepresentative of a system load where the test processes were actually competing with other processes, because they were run in a single process on an otherwise quiescent system. The second set match the overload behaviour I suggested that should be expected under overload conditions, where the overall performance degrades to (effectively) non-affinity performance. They noted these as issues, themselves, near the end of the email, without providing a real analysis as to why: | The results of this test series are: | | - - LinuxThreads indeed had several problems | | - - NGPT indeed run much faster (twice the performance) | | - - NPTL runs four times faster than NGPT in a benchmark which by all | means should favor an M-on-N implementation. This still misses the multiple benchmark processes running multithreaded simultaneously, which I think would demonstrate a third stair-step in performance. Note that there is probably a fourth, which would be missed, unless the test programs were copied to duplicate program inages, rather than running out of the same executable image file, to ensure against page sharing among the competing images. I'd still like to see *that* benchmark, because I believe it would be worst-case for the scheduler design, but common enough with, e.g., a mail server like sendmail, qmail, or postfix, or with Samba. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message