Re: Hard-limits for kern.maxproc
Re: Hard-limits for kern.maxproc
- Subject: Re: Hard-limits for kern.maxproc
- From: Michael Cashwell <email@hidden>
- Date: Fri, 6 Feb 2009 14:50:56 -0500
On Feb 6, 2009, at 2:38 PM, Steve Checkoway wrote:
On Feb 6, 2009, at 5:18 AM, Andrew Gallatin wrote:
As people have tried to explain, there are good reasons why the
limits are set the way they are. Remember, with a 32-bit kernel,
even if
you've got 8GB of RAM, the kernel itself can only use less than 4GB
of RAM for its own data structure (for example, trivial things like
the
process table :) So if you increase the process limits, you run a
real risk of running the kernel out of memory and/or kernel virtual
address space, leading to system crashes or hangs.
I'm not a kernel developer so maybe this is naive, but if running
out of memory is the issue, then shouldn't the limit be based on how
much physical memory there as as opposed to a fixed limit? It seems
like this number could be dynamic too, when the system is running
low on memory, start returning EAGAIN to fork() calls.
Under the 32-bit kernel it's really the kernel's virtual address space
that's scarce. (I chuckle that a 4GB resource is considered scarce
these days.)
As a side note, does the kernel not page out its own memory? It
seems like it should have access to more space using the same
mechanism, as long as it is careful about which data is truly on
disk and which is in memory.
"Normal" kernel memory is not paged because the pager is a userland
process. Having kernel threads (not userland threads that happen to
call into the kernel) block waiting for service from userland would be
a nightmare of deadlocks. And even if that were addressed you'd still
run afoul of the VA limit noted above.
The real solution here IMO is to get the the 64-bit kernel and then
adjust things.
-Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden