[ntp:questions] Linux and mlockall()

Michael Deutschmann michael at talamasca.ocis.net
Sat Dec 27 05:56:44 UTC 2008


I now have NTP-with-mlockall() installed and chiming on my Linux systems.

On Fri, 19 Dec 2008, Harlan Stenn wrote:
> Please see http://support.ntp.org/bin/view/Support/LockingNtpdInMemory and
> the related links on that page.
> 
> http://support.ntp.org/bin/view/Dev/NewNtpConfFormat#Memory_locking also has
> some information that might be useful.

I've looked into those links.  Sounds like the problem is not actually
mlockall(), it's setrlimit().

When using mlockall(), ntpd adjusts the stack limit downward, out of fear
that the operating system will deny the lock unless it can pre-commit real
memory for the worst-case stack size.

Glibc's resolver is apparently a stack hog, and chafes under a limit
which is otherwise comfortable for ntpd.

Denying mlockall() only solves the problem because then ntpd won't bother
with setrlimit().

If so, then the cure is simple: When a resolver process is forked, it's
first act should be to reset the stack limit to what it was in the first
place.  There's no worry about overcommitting real memory, because
mlockall() is not inherited across forks.

---- Michael Deutschmann <michael at talamasca.ocis.net>




More information about the questions mailing list