🚀 go-pugleaf

In article <61598@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:
> John Jay Feiler writes
> >> I've got a large image that I need to keep all in ram, at all times.
> 
> dan@az.stratus.com writes:
> 
> > any attempt to fool [the OS demand paging] results in slightly increased  
performance for
> > one particular application at the expense of  all the others.   
> 
> > the consensus [...] was that attempts to defeat the LRU demand paging  
algorithm  
> > were generally detrimental to overall system throughput and response  
time.
> 
> Dan gives alot of good arguments why its usually not a good idea to
> fight the demand paging system.  It does pay to understand how it works so  
you can
> take better advantage of it.  That means it pays to learn about zones, 
> copy on write optimizations and perhaps OS tuning parameters.

I know how demand paging works, as well as zones, etc.  In this case we have  
very specific reasons for wanting to defeat the paging mechanisms.  This is  
for a real-time turnkey app, not a general productivity tool.  We know  
exactly (well, pretty well at least) what will be running at the same time.

> There is one very legitimate reason for wanting to wire a page in physical
> memory irregardless of how frequently its accessed.  Thats is when it is  
needed
> to support a task with hard real time deadlines.

That's exactly the case here.  We have a large image from which we need to  
extract regions, then rotate them, etc.

The rlimit functions definitely do have an effect, because before we put in  
the rlimit call, the system NEVER gave us more than 7MB of "real" memory,  
regardless of how much was available (on a 64MB cube).  Now that we've set  
the data size to the maximum, we get a VSIZE of 22.2MB and a RSIZE of 19.2MB.  
(as reported by "ps -auxw")  Much better.


  Here the need is for predictability
> rather than speeed. Demand paging introduces uncertain delays in individual  
cases even if it
> increases the overall performance.  This uncertainty can make it impossible  
to prove that
> you will meet your deadlines.  (most of the time is not good enough)
> 
> except in this special case, where you are using your computer (typically)  
to
> control or track some physical system with hard real-time constraints,
> Dan's advice is quite sound. 
> 
> -- 
> ---------------------------------------------------
> Alex Blakemore alex@cs.umd.edu   NeXT mail accepted