From owner-freebsd-hackers  Sun Nov 12 01:24:17 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id BAA01501
          for hackers-outgoing; Sun, 12 Nov 1995 01:24:17 -0800
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA01488
          for <freebsd-hackers@freebsd.org>; Sun, 12 Nov 1995 01:24:09 -0800
Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA05990 for <freebsd-hackers@freebsd.org>; Sun, 12 Nov 1995 10:24:00 +0100
Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP
	id KAA03465 for freebsd-hackers@freebsd.org; Sun, 12 Nov 1995 10:23:59 +0100
Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id KAA18566 for freebsd-hackers@freebsd.org; Sun, 12 Nov 1995 10:01:04 +0100
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199511120901.KAA18566@uriah.heep.sax.de>
Subject: Re: That G&*()m process limit
To: freebsd-hackers@freebsd.org (FreeBSD hackers)
Date: Sun, 12 Nov 1995 10:01:04 +0100 (MET)
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
In-Reply-To: <14272.816152262@time.cdrom.com> from "Jordan K. Hubbard" at Nov 11, 95 08:57:42 pm
X-Phone: +49-351-2012 669
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 1743      
Sender: owner-hackers@freebsd.org
Precedence: bulk

As Jordan K. Hubbard wrote:
> 
> > With my current 2-CPU setup, fvwm and exmh get launched off a single
> > server, and apparently consume more than 100 child_proc PIDs apiece...
> > 
> > Jordan sets his to 400, maybe the default should be higher than 40?
> 
> No argument from me!

Perhaps it should be made dependant from the machine size (unless
overridden from the config file)?  For my 386sx/16 notebook with its 5
MB of RAM, 40 is certainly the upmost number that could reliably
prevent a ``while (fork()) ;'' from making the machine unoperable.

So what about:

	switch(cpu_class) {
	case CPUCLASS_286:
		printf("What the heck are you doing here?\n");
		exit(1);
		/* or does somebody know why CPUCLASS_286 is still there? */

	case CPUCLASS_386:
		proclimit = 20;
		break;

	case CPUCLASS_486:
		proclimit = 40;
		break;

	case CPUCLASS_586:
		proclimit = 50;
		break;
	}

	i = ptoa(Maxmem) / (4 * 1024 * 1024);

	/* calculate int(log2(i)) */
	for(j = 31; j >= 0; j--) {
		if(i & (1 << j))
			break;
	}

	proclimit *= (j + 1);


This would yield:

CPU & maxmem: 386 2	:-)
Your proclimit is 20
CPU & maxmem: 386 4
Your proclimit is 20
CPU & maxmem: 386 8
Your proclimit is 40
CPU & maxmem: 486 4
Your proclimit is 40
CPU & maxmem: 486 8
Your proclimit is 80
CPU & maxmem: 386 12
Your proclimit is 40
CPU & maxmem: 486 16
Your proclimit is 120
CPU & maxmem: 586 8
Your proclimit is 100
CPU & maxmem: 586 16
Your proclimit is 150
CPU & maxmem: 586 64
Your proclimit is 250
CPU & maxmem: 486 128
Your proclimit is 240
CPU & maxmem: ^C

I believe these are realistic defaults.
	
-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)