Re: mlockall() and small memory systems

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Thu, 24 May 2012, Martin Husemann wrote:

> On Wed, May 23, 2012 at 07:15:41PM +0100, David Laight wrote:
> > What are the default ulimit values?
> 
> Good point. Page size is 4k, with 32MB the limits are
> 
> # ulimit -a
> time          (-t seconds    ) unlimited
> file          (-f blocks     ) unlimited
> data          (-d kbytes     ) 65536
> stack         (-s kbytes     ) 8192
> coredump      (-c blocks     ) unlimited
> memory        (-m kbytes     ) 10664
> locked memory (-l kbytes     ) 3554
> process       (-p processes  ) 160
> nofiles       (-n descriptors) 128
> vmemory       (-v kbytes     ) unlimited
> sbsize        (-b bytes      ) unlimited
> 
> With 64 MB ram they are:
> 
> time          (-t seconds    ) unlimited
> file          (-f blocks     ) unlimited
> data          (-d kbytes     ) 65536
> stack         (-s kbytes     ) 8192
> coredump      (-c blocks     ) unlimited
> memory        (-m kbytes     ) 42776
> locked memory (-l kbytes     ) 14258
> process       (-p processes  ) 160
> nofiles       (-n descriptors) 128
> vmemory       (-v kbytes     ) unlimited
> sbsize        (-b bytes      ) unlimited
> 
> "Locked memory" sounds like what we run into - but shouldn't mlockall() return
> some error code if we exceed the limit?

Not necessarily.  If the code does mlockall() with the MCL_FUTURE flag 
then any *new* pages are also supposed to be locked into memory.  So if 
the process address space at the time the mlockall() is done is smaller 
than the locked memory limit, the mlockall() should succeed.  

But later if the mmap() makes the total process address space exceed the 
mmap() call should return an error instead of succeeding.  I think there 
may be a bug in mmap().  You should check to see if the mmap() causes the 
process to cross the locked memory limit.

Eduardo