Re: kernel paging (was Hard-limits for kern.maxproc)
Re: kernel paging (was Hard-limits for kern.maxproc)
- Subject: Re: kernel paging (was Hard-limits for kern.maxproc)
- From: Terry Lambert <email@hidden>
- Date: Sat, 07 Feb 2009 03:14:40 -0800
On Feb 7, 2009, at 12:39 AM, Steve Checkoway <email@hidden> wrote:
Thank you Terry, Michael, and Michael. That's all very interesting!
Kernel design decisions are always fascinating.
Just to be clear, I understand the kernel virtual address space
being the scarce resource. I was asking about the possibility of
using a mechanism similar to paging where it was actually reusing
portions of the virtual address space. Of course, demand-paging
wouldn't be possible since the same (virtual) addresses would refer
to different data, depending on some context. Given the apparent
complexity of normal paging, my idea seems completely infeasible.
v7 UNIX, CP/M, MP/M, and DOS used to use an approach called overlays
to do exactly this. v8 and v9 UNIX also did this (they had to fit in
the 16 bit address space of the PDP hardware, meaning 64K of code and
64K of data, at best), but you are unlikely to find them anywhere.
To do this, you still have to break the dependency relationship
between overlays and overlay code: code that is loaded in an overlay
can't depend on other code in the same overlay region.
It is possible to do this for third party drivers using a technique
called static analysis. This is relatively straight forward for fix
sized aligned instructions -- call them ppc and arm -- and a lot
harder for variable sized instruction set processors. You effectively
look at the code and decide the subtrees of code that will be used for
a given set if code: the functions called by the functions called by
the ... even through calls through funtions pointers or vtables.
So it's doable, but the amount if effort involved would be more than,
for example, moving the graphics card push pages out of the kernel
address space, which would be an order of magnitude win over that
approach.
-- Terry
_______________________________________________
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