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: Sat, 7 Feb 2009 00:14:14 -0500
On Feb 6, 2009, at 11:49 PM, Michael Smith wrote:
"Normal" kernel memory is not paged because the pager is a userland
process.
Assuming you are still talking about Darwin here, that's simply not
true at all.
Pages are cleaned by a reasonably high priority kernel thread. The
issue is not priority inversion, it's that determining pre-facto the
working set for the pageout path is NP-hard.
OK, but what confuses me then is that if the issue is not priority
inversion (which is another name for deadlock) then why is pre-
computing the working set for the pageout path necessary? Is it that
if the pageout code (or data) itself were paged out then you're stuck?
If that's it, I'm surprised that some sort of memory pool dedicated to
that task couldn't confine those elements to one wired memory region.
Wiring most of the kernel to protect just that seems draconian. (I'm
not saying that the pageout code and data aren't important just that
it would seem they could be isolated.)
I suppose that's tough given that all manner of IOKit drivers related
to disk IO (and raid) might be involved.
-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