From owner-freebsd-arch@FreeBSD.ORG Thu Apr 3 14:03:59 2003 Return-Path: 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 BE8C437B401 for ; Thu, 3 Apr 2003 14:03:59 -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 0E83143FD7 for ; Thu, 3 Apr 2003 14:03:59 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0138.cvx21-bradley.dialup.earthlink.net ([209.179.192.138] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 191CoK-0006J8-00; Thu, 03 Apr 2003 14:03:53 -0800 Message-ID: <3E8CAF7C.7729D532@mindspring.com> Date: Thu, 03 Apr 2003 14:02:36 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Sysoev References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a403c6c5176e1190e1c6de8bb145b57f9893caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: freebsd-arch@freebsd.org Subject: Re: libthr and 1:1 threading. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 22:04:00 -0000 Igor Sysoev wrote: > On Thu, 3 Apr 2003, Terry Lambert wrote: > > I have to ask: > > > > Why is it so important to people that the libthr performance > > gains be impossible to achieve without use of the 1:1 model, > > rather than a modification of libc_r, or avoidance of existing > > kernel latencies? > > If you mean that "people" is my humble person then I want to say > that I am not against 1:1 model libthr, KSE's M:N model, current > or improved libc_r, rfork()ed LinuxThreads and any possible future > threads implementation. I didn't mean you specifically. > My last emails were caused only by your incorrect statements about > a non-blocking behaviour of Solaris disk files. When you referenced Solaris 8, rather than contradicting you, I looked at the source code and immediately admitted that I was wrong and you were right, so I don't see why this has continued. Can you do the same with regard to the fact that, even if the current implementation does not use the flag in its implementation of disk I/O, that it does not prohibit setting the flag, and it does not prohibit a third party, such as Veritas or some other disk FS provider, from implementing it? As I said before, I used this flag to great effect on SVR4.0.2 and SVR4.3 in the NetWare for UNIX product in 1994: it provided a 12% performance improvement, by prefaulting the first 9K of Windows executable files stored on Novell servers, and accessed from Windows (Windows repeatedly re-references the first 9K in loading executables, or used to in the WIN32 and Windows95 era). At the time, the effect was measurable on Solaris as well, and it was designed with the source code to the OS in hand for both SVR4 and Solaris, which had just been finished being jointly integrated at the time. That Solaris can't do this any more in more recent versions of Solaris is a loss of functionality, not a feature. -- Terry