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 <[email protected]> _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
