One thing I thought I knew about the standard NTP distribution, was that it uses the mlockall() call, when available, to prevent swapping and thus gain more repeatable latencies.
However, recently I had cause to run "nm" on ntpd, and was surprised to note no references to mlockall(). A check with "ps" confirmed that ntpd was indeed no longer locked in memory. I checked the source, and it seems back in 2004 someone altered the source to suppress detection of mlockall() on Linux (my platform), citing "resolver problems". I haven't seen any discussion of this on this newsgroup yet. Considering that people who object to mlockall() usage on the grounds that it prevents running stock ntpd on limited-real-memory toasters have been given the cold shoulder, four years is a long time to deprive Linux users of its benefits. Since ntpd does its resolving from a secondary process, it would seem that the problem could be avoided by moving the mlockall() call to after the "intres" process is forked. "resolver problems" probably wouldn't bite me, since I use IP addresses only in my configuration files, so that I can start ntpd before named. So it should be safe for me to hack the configure script so mlockall() is used anyway, right? Also, calling this a "Linux" problem is likely careless. I'd imagine the root of the incompatibility is probably in the GNU libc that is widely used with the Linux kernel. ---- Michael Deutschmann <mich...@talamasca.ocis.net> _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
