Subject: lazy mlock?
To: None <tech-kern@netbsd.org>
From: Richard Earnshaw <rearnsha@buzzard.freeserve.co.uk>
List: tech-kern
Date: 04/16/2002 23:03:15
I was watching a machine of mine thrashing itself to death today (well, 
nearly) as it tried to compile a c++ file with a process size of ~60Mbytes 
(the machine only has 32M of RAM) and I got to wondering why the process 
had a maximum RSS of only 12M of RAM even when it was the only process 
running.

The problem was that ntpd was locking about 6M of RAM (~20%) down and 
killing that solved most of the thrashing issues.  This got me to 
wondering if there was any way to make ntpd kinder to the system: it's 
well known that ntpd has a lot of code that just isn't needed on most 
machines.

A random idea that I had would be that instead of blindly locking every 
page in the executable into memory we should only lock down those pages 
actually required.

So, how hard would it be to add a syscall that would only lock a page into 
memory if it were really needed?  That is, we start with an empty set of 
locked pages, then as a page is referenced it is loaded and locked in 
place (so that it won't be swapped out again later).  This way, pages that 
aren't referenced will never be locked, and pages that are will only pay 
the fetch cost once (on first reference).  For something like ntp this 
would surely be perfectly adequate.

R.