Subject: Re: NetBSD1.6 UVM problem?
To: None <tech-kern@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 12/10/2002 15:10:09
>> You call mlockall(), or if you can, mlock(), to lock all relevant
>> pages into core.  Or [...]
> `mlock' only provides you with a way to find out if there is still
> any physical memory available for allocation in the system.

That's not how the manpage describes it.  The manpage says that it
locks virtual pages into core, that is, it arranges that accesses to
them will never incur page faults.  This does imply finding physical
pages to back them, yes, but it does a lot more than that.

> Moreover, not every VM use case requires locking of all the pages in
> RAM.

No...but if you want to avoid the process running into trouble bceause
the OS is out of physical pages during a page fault, one way is to
ensure that it never page-faults.

>> I can see only about four reasonable things to do when you're out of
>> RAM when servicing a page fault:
>> 1) Deliver a signal to the process.
>> 2) Kill the process.
>> 3) Stall: make the process wait a little [...]
>> 4) [S]tall the faulting process and kick someone else, [...]

>> For (1) to be useful, the process must have arranged to handle the
>> signal without incurring further page faults, which is possible but
>> nontrivial [...]

> (2) we've got now and it's acceptable,

Acceptable for some purposes (the machine on my desktop, for example).
Not acceptable for lots of other purposes.

> (3) and (4) don't look feasible to me in most cases,

Not feasible as in hard to do, or as in not helpful?  When I looked at
the code (which was pre-1.6, but not by much), it wouldn't've been hard
to do either one.  Ugly in somke respects, maybe, but not hard.

> (1): Locking of the signal handler code shouldn't be a problem, it's
> relatively small when not abused.

The problem is making sure you've found all the relevant code.  You
need to lock not only the signal handler but anything it calls, and all
data structures accessed....

I wonder if there would be any use for something like an MCL_LAZY flag
to mlockall, which basically says "don't lock anything now, but start
remembering what pages are touched" and then MCL_LOCKLAZY which says
"now, convert everything touched since the last MCL_LAZY to real locked
pages", so as to permit locking data structures by setting LAZY,
accessing them, and then calling LOCKLAZY to do the locking -
regardless of whether they're all on one page or scattered throughout
dozens.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B