From owner-freebsd-smp Tue Jan 28 00:01:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA28958 for smp-outgoing; Tue, 28 Jan 1997 00:01:51 -0800 (PST) Received: from kvikk.uit.no (kvikk.Uit.No [129.242.4.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA28953 for ; Tue, 28 Jan 1997 00:01:47 -0800 (PST) Received: from sprint.cc.uit.no (sprint.Cc.Uit.No [129.242.5.198]) by kvikk.uit.no (8.8.5/8.8.5) with ESMTP id JAA12547; Tue, 28 Jan 1997 09:01:42 +0100 (MET) Received: from slibo.cc.uit.no (slibo.Cc.Uit.No [129.242.5.36]) by sprint.cc.uit.no (8.8.5/8.8.5) with ESMTP id JAA11216; Tue, 28 Jan 1997 09:01:41 +0100 (MET) Received: from localhost (terjem@localhost) by slibo.cc.uit.no (8.8.5/8.8.5) with ESMTP id JAA15200; Tue, 28 Jan 1997 09:01:40 +0100 (MET) Message-Id: <199701280801.JAA15200@slibo.cc.uit.no> X-Mailer: exmh version 1.6.9 8/22/96 To: Steve Passe cc: smp@freebsd.org Subject: Re: Current SMP status inquiry In-reply-to: Your message of "Mon, 27 Jan 1997 19:35:38 MET." <199701280235.TAA00396@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 1997 09:01:39 +0100 From: Terje Normann Marthinussen Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Hi, > >> What about the evil FP exception/FPU support problem? The one that >> locks everything up solid? I'd be happy to write up a description and >> workaround, but it may be that others don't believe it exists, or that >> it is simply a problem with my and a few others equipment. > >it definately seems to affect some hardware more than others. I recently >ran 3 copies of ico on X11 for 3-4 houres without a burp. There has to >be a fair amout of FPU use going on during that. > >This does need to be pursued, but I have no time (or even an SMP machine) >to give to it right now, a "real job" has arrived... I got our 4CPU pentium HP Netserver up on current early last week, and during the weekend we had it chewing through 1GB+ of gzip'ed log data. Two processes fed with each half of the data, they grew to around 50MB each (early memory inefficient version of the program and we "only" have 128MB on it so 2 was enough). While not FPU intensive, it most certainly must have used quite a bit of FPU during the ~15 hours the processes ran (well, actually two runs of ~15 hours, a bug was discovered ;)). Didn't notice any problems at all. Terje Marthinussen terjem@cc.uit.no