Re: Hard-limits for kern.maxproc
Re: Hard-limits for kern.maxproc
- Subject: Re: Hard-limits for kern.maxproc
- From: Michael Smith <email@hidden>
- Date: Fri, 6 Feb 2009 20:49:26 -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.
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.
On Feb 6, 2009, at 12:02 PM, Steve Checkoway wrote:
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?
There are lots of operating systems and lots of crazy ways to do
things. Pagetables are among the more worthless things to page out in
the Darwin case because they are almost entirely derivative; you can
regenerate a task's pagetable from its VM map (this is a side-effect
of lazily generating the pagetable in the first place).
However, tossing out pagetable pages is rarely a big win and even less
so on Darwin because as has been noted previously, the scarce resource
is kernel virtual space and pagetables are not mapped there.
How do other *nix systems accommodate a much larger process limit on
32 bit?
Darwin starts at a large disadvantage by mapping the entirety of the
graphics adapters' onboard memory into the kernel virtual address
space. This is good for performance that matters to Apple, but it
cramps things elsewhere.
There is also a philosophical argument to be made in constraining the
number of tasks/threads that the system will permit to be run.
Typically these high thread/task count models are using the thread/
task to store a (frequently small) amount of context, which is usually
pretty inefficient.
In a common example, you're committing the kernel to maintaining a
fairly large amount of data (the proc/task structures, your VM map
&pagetables, all the crap your frameworks' init paths dirty, etc.
etc.) just so that you can keep track of the association between a
network socket and a username/password combination.
This is sloppy programming, and encouraging it is, IMO, immoral.
Tiger introduced a couple of features (most particularly the concept
of per-thread credentials) that were specifically aimed at removing
one of the arguments ("but I need to associate the connected identity
with its actions") for the excess task model. It's reasonable to view
GCD and some upcoming SnowLeopard features in the light of this
argument (though this is by no means the only justification for them)
as it applies to the excess thread model.
= 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