Re: Hard-limits for kern.maxproc
Re: Hard-limits for kern.maxproc
- Subject: Re: Hard-limits for kern.maxproc
- From: Steve Checkoway <email@hidden>
- Date: Fri, 6 Feb 2009 12:02:57 -0800
On Feb 6, 2009, at 11:50 AM, Michael Cashwell wrote:
On Feb 6, 2009, at 2:38 PM, Steve Checkoway wrote:
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.
Interesting. I'm pretty sure the undergraduate and graduate
architecture books I have mention paging out portions of the page
table being a common thing to do. Is that a case of academia not quite
matching up with the real world, or just out of date?
The real solution here IMO is to get the the 64-bit kernel and then
adjust things.
How do other *nix systems accommodate a much larger process limit on
32 bit?
--
Steve Checkoway
"Anyone who says that the solution is to educate the users
hasn't ever met an actual user." -- Bruce Schneier
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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