Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!msunews!news.mtu.edu!newsxfer.itd.umich.edu!newsxfer3.itd.umich.edu!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!newsfeed.nacamar.de!supernews.com!news.iquest.net!not-for-mail From: "John S. Dyson" <dyson@freebsd.org> Newsgroups: comp.unix.bsd.freebsd.misc,comp.sys.sgi.misc Subject: Re: no such thing as a "general user community" Date: Wed, 26 Mar 1997 00:43:14 -0500 Organization: John S. Dyson's home machine Lines: 42 Message-ID: <3338B772.41C67EA6@freebsd.org> References: <331BB7DD.28EC@net5.net> <332F69B8.1CFBAE39@freebsd.org> <5h5jgr$et4$1@news.clinet.fi> <5h91l2$gua@innocence.interface-business.de> <5h9rr0$2sj@flea.best.net> NNTP-Posting-Host: dyson.iquest.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 3.0-CURRENT i386) Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:37777 comp.sys.sgi.misc:29417 Matt Dillon wrote: (Quote very severely cropped :-)). > > Sometimes the kernels get confused and have to > be rebooted to regain performance or resources, though this has happened > less often in recent times (except the paging code is still extremely > broken in terms of its performance under load). > One of my consulting jobs was to support a variant of SVR4 on MIPS-based boxes. (I had full permission to work on both FreeBSD and this project.) I don't know how similar to IRIX is to the SVR4 variant, but there were very severe performance problems under certain load conditions. Specifically, there was significant TLB thrashing (and the TLB fault overhead was a problem.) Additionally, the paging algorithm was significantly degraded over the SVR3 one, and fell flat very very quickly. It was almost an optimal thrash algorithm :-). I have heard alot of things about how good and adequate the clock (and its variants) algorithm is, but every time that I play with the FreeBSD paging algorithms -- the clock algorithm (which SVR4 has a very poor implementation of) looses the race. If I had continued at the position, I think that I would have gotten permission to fix the paging algorithm. The SVR4 variant had other fixes to mitigate alot of the TLB thrashing problems, but still was a bit of a problem. The shared lib implementation in that SVR4 variant had severe problems with excessive TLB usage -- and performance degraded badly when shared libs were used. With judicious use of linking processes statically, the system performance (under light and medium loads) went up amazingly. But heaven forbid when the system started paging -- that wonderful performance fell through the toilet. Fixing the SVR4 algorithm is not brain surgery, and would likely take me < 6mos, given the proper resources. (Cynical comment follows -- no flames intended :-)): Of course, hardware vendors probably like to sell memory at grossly inflated prices, so making paging work well might be counter productive to their cause... John