Re: mlockall() semantics

[Sad Clouds <cryintothebluesky%googlemail.com@localhost>]

On Tue, 12 Oct 2010 21:45:36 -0500
David Young <dyoung%pobox.com@localhost> wrote:

> On Tue, Oct 12, 2010 at 03:55:51PM +0100, Sad Clouds wrote:
> > I run a process that does the following:
> > 
> > Call mlockall(MCL_FUTURE)
> > 
> > Run a loop, calling malloc() for a large number of objects. Object
> > vary is size, from 1K to 1MB. Total memory allocated is about 1GB.
> > 
> > Looking at the output of 'top' command, it shows 'Wired' memory to
> > be 666MB, which is much less than 1GB.
> 
> Your process may not have touched every page of the malloc()'d memory,
> so they're not all mapped.
> 
> Dave

Hi Dave, I think it does touch every page. What the process is doing is
this - for every file under /usr/src it calls stat() to get file size,
then it calls malloc() for the file size, then it does read() of file
contents into allocated memory segment. This is just part of a simple
benchmark I wrote.

What I'm trying to understand is why only 666MB get locked, and not the
rest. System allocates physical memory in pages, so in theory it should
be locking one page at a time, even if malloc() allocates only, say %5
of pages' size. Any future memory allocations from the same page,
should be already locked.

This is what the "BUGS" section of mlockall(2) says:

"The per-process resource limit is a limit on the amount of virtual
memory locked, while the system-wide limit is for the number of locked
physical pages.  Hence a process with two distinct locked mappings of
the same physical page counts as 2 pages against the per-process limit
and as only a single page in the system limit."

So if NetBSD's mlockall() implementation locks the same page multiple
times (this doesn't seem like a smart think to do), then maybe my
process is running out of 32-bit virtual memory limit?