🚀 go-pugleaf

John Jay Feiler writes
> I've got a large image that I need to keep all in ram, at all times.  I've  
> used get/setrlimit(RLIMIT_DATA,rtp) calls to set the data limit to the  
> maximum, and that definitely seems to help ...

More physical memory would certainly help, but basically all you have to do to  
keep it in ram is to touch the page frequently enough. If you don't touch it  
and some other application needs the physical memory then the other application  
gets it.   If you're not accessing it frequently enough to keep it in memory,  
then it seems to me that it doesn't really need to be in memory.  That's how  
demand paging systems work, and usually any attempt to fool them results in  
slightly increased performance for one particular application at the expense of  
all the others.   

> ... but is there any way to wire down  
> pages of ram from an application?  If that isn't possible, would it be  
> possible to write a LKS that wired down the pages for the image, and made  
> that chunk of ram available to another app?

I think you're missing the point.  Wiring a page means making it unavailable
for participation in the pool of pages used for demand paging.  If you should  
find a way to wire the page, you sure won't have "that chunk of ram available  
to another app."   Quite the opposite;  that chunk of RAM will be dedicated.

I've done some awful kludgy things in the past, including some code for a  
former employer that was called "belly warmer" code -- it deliberately 
forced pages to be assigned to physical pages by periodically touching at least  
one byte in the page (thus keeping them warm).  This was in the early days,  
when we used 68000 cpu's that couldn't handle their own page faults.  So, the  
solution was to freeze the clocks of the user cpu, interrupt the exec cpu (that  
always executed wired code) and have the exec cpu resolve the page fault, at  
which time the user CPU could be restarted.   So, you see, page faults were  
VERY expensive, and we went to great lengths to prevent them.   However, the  
consensus, after some time, some newer hardware (68010), and a few more  
releases of the OS, was that attempts to defeat the LRU demand paging algorithm  
were generally detrimental to overall system throughput and response time.

I hope I've convinced you to look elsewhere for a solution.

--
L. W. "Dan" Danz         (WA5SKM) VOS Mail:  Dan_Danz@vos.stratus.com
Sr Consulting Software SE         NeXT Mail: dan@az.stratus.com
Customer Assistance Center        Voice Mail/Pager: (602) 852-3107
Telecommunications Division       Customer Service: (800) 828-8513
Stratus Computer, Inc. 4455 E. Camelback #115-A, Phoenix AZ 85018