> True, but that doesn't help solve the problem.  If I'm writing an
> application with the approximate size, configurability, and complexity
> of ntp, I don't necessarily know which parts of the application
> will be in use, how much stack space will be used, etc.  If I don't
> want the necessary parts to be paged out, but I don't know what my
> working set is, I am forced to attempt to mlock() more than I
> strictly need because I don't *know* what I necessarily need.
> ulimit can limit the amount of locked memory, sure, but that doesn't
> help optimize the amount that will be locked--it may simply prevent
> the application from running.
>
> I think the lazy mlock() is an excellent way for the kernel and
> application to work together in a way that minimizes overall program
> (application + kernel) complexity while maximizing efficiency.
> This makes sense to me and seems to be a natural extension of a
> demand-paged virtual memory system as a whole.

Well said Allen!

Indeed, many such programs will have their critical working set size and
location(s) change over time (either gradually or even suddenly due to entering
a different phase in their processing). This is a problem which has been faced
(successfully) by other systems in the past, and really isn't all that hard to
solve either.

A sample solution is to provide a means for the (appropriately privledged)
program to indicate how many pages in its working set are "important", without
having to indicate which they are. The operating system then takes
responsibility for keeping the most recently used of this program's working set
pages as the prefered ones to remain resident. Consider this a "soft locking"
facility. In the system I am most familiar with this was refered to as setting a
"reserved page count" as opposed to performing a hard "locking of pages".

Since most sophisticated paging systems today already understand how to keep a
program's most recently referenced pages when choosing what pages in memory to
page out, it is relatively easy to see how to extend this to simply keep at
least "n" pages for such a flagged process.

This is a highly useful concept that has real world applicability in many
situations beyond just ntp.

Peace. -njg