Date: Mon, 21 Apr 2003 21:09:15 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Narvi <narvi@haldjas.folklore.ee> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com> Subject: Re: libkse -> libpthreads Message-ID: <3EA4C06B.F607710C@mindspring.com> References: <20030422055559.L33034-100000@haldjas.folklore.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
Narvi wrote: > On Mon, 21 Apr 2003, Terry Lambert wrote: > > Narvi wrote: > > > If by "now" you mean Solaris 9, then yes, this is so. This is not a > > > fundamental issue, merely how kernel API-s are used. On Solaris 8 you get > > > both the "old" M:N version and the Solaris 9 style 1:1 version in > > > /usr/lib/lwp. There is no way to tell what it will be in Solaris 9+x for > > > some arbitrary positive value of x. > > > > Right. The liblwp in SunOS 4.1.3_U2 (first appearing in SunOS 4.0.2, > > I believe) is a totally different liblwp, as well (just the same name); > > LWP used to be a purely user space abstraction. > > > > I don't think there is a liblwp in modern solaris, lwp remains only as a > name for kernel threads. /usr/lib/lwp is just a directory containing > alternative threads libraries on solaris 8 and is a symbolic link to > /usr/lib on solaris 9. 4.1.3_U2 and 4.0.2 are circa the late 1980's. > > I've heard it anecdotally claimed that Sun made the change to > > avoid bugs; I've also heard it anecdotally claimed by Sun > > engineers that they made the change because they don't have > > the man power remaining to perform ordinary maintenance on a > > lot of their existing code base. Perhaps they were just > > disgruntled, and the first excuse is the correct one... ;^). > > the claim in the man page(s)/whitepaper(s) is about perfomance though - > but as always, these would be claims about a particular implementation and > freebsd one might not run into whichever problems caused the speed loss on > solaris. It wouldn't. The main issue as far as performance went, and why we (Novell USG) used processes instead of SVR4 threads, and did file descriptor table sharing, and shared client context data in a shared memory segment (8-)) is that SVR4-derived systems without a unified VM and buffer cache do a lot of page thrashing. One of the "innovations" in Solaris 9, if you read the white papers, is that they reintroduced a seperate buffer cache. It makes sense that in doing that, they would reintroduce the same performance problems that came from having a seperate buffer cache in the first place. Probably the correct thing to do instead would have been to introduce a seperate working set quota on file objects, so a single file being randomly accessed couldn't LRU out all the other files in the system. 8-). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EA4C06B.F607710C>