On Tue, Jun 12, 2001 at 07:52:08PM +0200, wojtek@wojtek.3miasto.net wrote:

> > > > inefficient way of implementing kernel threads", but I haven't really
> > > > heard any arguments as to why it necessarily has to be? Why would it
> > > 
> > > because context switching takes time, especially in linux with lots of
> > > processes.
> > 
> >  Do you have concrete numbers, do you? Could you please show us them, it's
> 
> naver made any measurements with numbers. just tried to run 2000 sleep 1h
> processes in background as root and looking at general system slowdown
> after it (no swapping)

On the other hand, NetBSD ran my own little test program twice, and the
OS crashed on the second try. Got a malloc panic in kmem_map and down it
went.

Same thing happens when trying to harden my server against mdaemon.

I probably need to increase some sort of limit. The first few tests with
only about 200 processes killed all of my login shells.

In any case, Linux created the processes quite fast, but pause for 30
seconds before the first kill() from the parent returned. Then then took
off pretty fast. It is something I would like to tune the kernel for,
but there isn't enough serious documentation for that yet.

NetBSD didn't have long pauses, but was slower than I expected in
creating the child processes, and every 50-100 processes it would pause
a bit, which I did expect.

But this crashing has gotta stop... 

Ah, when it rains it pours... I have sup set to update sources to
release 1.5 and it's pulled in the 1.5.1beta kernel.  That's not
what I wanted.


-- 
"Secrecy is the beginning of tyranny." -- Unknown