On Tue, Dec 10, 2002 at 03:10:09PM +0100, der Mouse wrote:

> 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.
> 
> >> 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.

Wouldn't hacks like AIX's and this one require most applications that need
to be safe to become unportable, platform dependant? Unless we add transparent
support for these facilities in libc? In which case all applications could
have the same execution safety but this wouldn't be suitable for any
emulation imho.

I personally think that it's a kernel-level only thing, and that although it
may take some time, a solution to kill the most demanding processes rather
than a random one would be best... Applications aware about safety would
make sure to not exceed a reasonable size... For instance, internet server
daemons usually respect the limits as specified by the administrator on
the number of simultaneous clients it should serve, etc; and would generally
not fall in the category of a process automatically killed for causing
out of swap conditions...

Matt