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.