Jim Helman (jimh++at++surreal)
Sat, 18 Feb 95 18:48:16 -0800
The usual approach for database paging is to design the database
and system memory configuration so that the currently active
portion of the database (that which is visible or could soon be
visible) always fits, and the application always pfDeletes
portions which are unlikely to be needed again soon.
Your approach uses a general LRU caching strategy to avoid
potential reloads. Given the slow database loading times of
most Performer 1.2's optimizing loaders, this makes sense.
Given the fast database loading rates coming soon, I think the
delete-as-much-as-you-can strategy makes more sense. In
particular, most vis sim applications striving for a fixed frame
rate will design for the worst case, which means they cannot
depend on the luck of reusing something left in the cache by a
particular flight path.
Also, by running so close to full memory utilization, you are
increasing the probability of memory fragmentation that could
affect a long-running application that does a lot of paging.
Since you are probably using all or most of swap space, you
are doing virtual memory paging to and from disk as well. I
believe that this can also have bad implications for real-time
determinism, in particular, I think paging can provoke TLB or
cache flushes.
Still, I can imagine applications where fixed frame rate is
less important where a cache type strategy would be a good choice.
> Is there a possibility to handle that case in an other way than just to exit?
> Can I set up a handler preventing the application from exiting when an error
> of a notification level of PFNFY_FATAL appears?
Not currently. But I think it would be reasonable for us to
change pfNotify so that the return value from a notify handler
could signify that a task should be retried, in this case pfNew's
amalloc(). Perhaps in a future release.
rgds,
-jim helman
jimh++at++surreal.asd.sgi.com
415/390-1151
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:58 PDT