Subject: Re: your mail
To: None <tech-kern@NetBSD.ORG>
From: Kevin P. Neal <kpneal@unity.ncsu.edu>
List: tech-kern
Date: 11/22/1995 18:54:42
Uh, no. My Sun 3/260 (8meg RAM, 50meg swap) running SunOS 4.1.1 ran for 55
days in a dorm with no crashes. We beat the heck out of this machine. 

I lived in the Computer and Technologies Theme program at the time, and I
lived with about 80 other computer geeks like me. Most of them were Linux
guys with spiffy new PCs. Then there was my machine, heating up my room.

They got mad, and one night one tried to crash my machine. He ran 500 
processes at one time. I heard about this the next day as I was reading
my email at the machine.

The best was when I was compiling ghostscript, make -k -j. About 50 gccs
running at one time, with more being spawned all the time. When it ran out
of ram + swap, either 1) ld.so would "just say no", or 2) gcc would just
say "ram? none here." and exit. The machine ran for another 20-30 days 
after that, until the power went out.

You know, I feel bad for all of the commercial OSs that are based on Mach.
That's alot of people trying to fix bugs in a system that was designed for
research and thats all. 

Or are these "far beyond bugs". These sound like fundamental problems in 
the Mach VM design. Where is the line between a Mach VM problem, and a
problem with the integration of BSD and Mach VM? 

Another question: How do I kill a process that is locked inside the 
kernal space because of a locked system call? I had this happen 3 times 
on an Alpha NetBSD box (this one here) and then finally the machine just
locked solid.

XCOMM --------------------------------------------------------
XCOMM Kevin P. Neal, Sophomore CSC/CPE     kpneal@eos.ncsu.edu 
XCOMM North Carolina State University      kevinneal@bix.com
XCOMM --------------------------------------------------------

On Tue, 21 Nov 1995, Chris G Demetriou wrote:

> > [Apparently], Frank van der Linden <frank@fwi.uva.nl>  writes:
> > >> The main problem is, that the VM system does not know about the existance
> > >> of the I/O buffer cache.k
> > 
> > cgd replies:
> > 
> > >hah.  you can work around that.
> > 
> > >the main problem is that if you malloc() (sizeof RAM) + (sizeof swap),
> > >the system will crash.
> 
> in no environment is the system safe from the "out of space" problem.
> Also, the "out of space" problem will easily crash -- actually, not
> even crash, just hang -- a machine, which means that it's very, very
> useful for denial of service...
> 
>