Re: mlock() issues

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

On Thu, 21 Oct 2010 19:13:13 +0100
David Laight <david%l8s.co.uk@localhost> wrote:

> A non-root user can then increase its own limit to 1/3 physmem, and
> root can change its own 'hard' and 'soft' limits to any value it
> cares.

I think for some applications, having control over locking the entire
physical memory can be a significant advantage. For example, for a
network file server you can design a caching subsystem, which caches
frequently accesses files and locks them in memory. On Linux or
Solaris, you can mmap() those memory segments with larger pages to
reduce TLB misses.

The main benefit of locking is it guarantees those memory pages have
not been flushed to disk, so your main threads never need to block. Any
access to files not in your cache is done asynchronously, via a
threaded I/O subsystem.

I do realise this reinvents kernel file cache, but it gives you a lot
more flexibility over what files get cached in memory and you can plug
custom algorithms over how files get evicted from cache.