Keep a file in memory an any cost

Bryn M. Reeves bmr at
Wed May 11 19:08:04 UTC 2011

On 05/11/2011 07:58 PM, JD wrote:
> mlock(2):
> int mlock(const void *addr, size_t len);
> can lock user virtual pages to memory (if user has the privileges).
> But when it comes to a file, you have no way of knowing the VA of the 
> pages in
> which a file is stored, so you will not be able to call mlock(2) with 
> the right VA.

Actually if used properly mlock works pretty well - see the LVM2 example I gave.
Just use mmap to map the region of interest into the process address space
(obviously it will need to fit but not a problem on a real computer ;).

There can be surprises however and this is the reason that LVM's use is "fancy";
the fedora locale-archive (part of glibc-common) is quite large today to contain
strings for the wide range of supported languages in Fedora.

On my f15 desktop it's around the 96M mark:

$ pmap $$ | grep locale-archive
00007f140b684000  96836K r----  /usr/lib/locale/locale-archive

On very low memory systems this can lead to problems with apps that want to lock
all pages of their address space into RAM (oom kills etc.). LVM avoids this by
blacklisting certain mapped files from mlock operations (see cvsweb link,
_memlock_maps(), _maps_line() and _blacklist_maps[]).

> Furthermore, a file is not necessarily all brought into memory IN CONTIGUOUS
> VIRTUAL PAGES of the system's filecache. So, obviously, mlock would not 
> help.

Does not matter. We're talking process address space not page cache.


More information about the users mailing list