Date: Tue, 21 Feb 1995 03:51:57 -0800 From: David Greenman <davidg@Root.COM> To: Bruce Evans <bde@zeta.org.au> Cc: jhs@regent.e-technik.tu-muenchen.de, current@FreeBSD.org Subject: Re: Possible kern.maxproc fatal bug Message-ID: <199502211152.DAA00893@corbin.Root.COM> In-Reply-To: Your message of "Tue, 21 Feb 95 19:18:14 %2B1100." <199502210818.TAA10312@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>As last line in my /etc/rc.local I used to have >>> sysctl -w kern.maxproc=300 >>>An innocent >>> cd /usr/ports ; make -i >>>would then always crash the system (even when compiled as normal user, >>>& with everything in ports having been changed to owner jhs (thus no suid 0 >>>stuff lurking in /usr/ports)). > >> Probably because the proc table is not dynamically sized. Basically, you >>can't change maxproc - it probably should not by managed by sysctl. > >But it is dynamically sized. I can't see any problems that would cause >a panic. Not completely. The problem is that the upages must be mapped in kernel memory. There used to be a problem with allocation failures caused by map fragmentation...until I created a seperate map to contain the upages (kernel stack and 'u' info). The size of this map is calculated at startup time and effectively sets the upper maximum on the total number of processes to whatever "maxproc" was at startup time. Other than creating a "balance set", there really isn't any way of working around this problem other than making the map much large than maxproc (and thus allow maxproc to grow much larger). Perhaps making the map accomodate 2 or 3 times maxproc might be a compromise. -DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502211152.DAA00893>