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: Steve Checkoway <email@hidden>
- Date: Sat, 7 Feb 2009 03:34:34 -0800
On Feb 7, 2009, at 3:14 AM, Terry Lambert wrote:
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.
Interestingly enough, I'm looking at an older 16-bit embedded system
that takes this approach. By carefully maintaining an overlay call
stack (I don't have a better name for it) and a table of functions and
which overlay they are in, it's possible for one function to call
another function in a different overlay by calling a helper function
that's always mapped into the address space that remaps the other
region. In this case, the code resides in several ROMs and the mapping
can be changed by a single instruction. Obviously it'd be more
complicated to do in a general purpose kernel.
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.
Certainly this is not decidable in general by straight-forward
reduction from the halting problem. When is the analysis happening?
When the driver is loaded into the kernel?
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.
I'm not entirely sure what graphics card push pages are, but it seems
pretty clear that an overlay approach is complex, one that seems
unnecessary given a larger kernel virtual address space.
As always, thanks for the fascinating look into the computing past.
--
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