>>> In article <%sbusjd...@khar-pern.talamasca.ocis.net>, Michael Deutschmann >>> <mich...@talamasca.ocis.net> writes:
Michael> One thing I thought I knew about the standard NTP distribution, was Michael> that it uses the mlockall() call, when available, to prevent Michael> swapping and thus gain more repeatable latencies. Yup, and if there is enough memory on the box that it doesn't swap, there is less need for mlockall(). As I recall, there are OSes wher mlockall() will reserve "extra memory for the future", and that may be where the problem lies. Michael> However, recently I had cause to run "nm" on ntpd, and was Michael> surprised to note no references to mlockall(). A check with "ps" Michael> confirmed that ntpd was indeed no longer locked in memory. Michael> I checked the source, and it seems back in 2004 someone altered the Michael> source to suppress detection of mlockall() on Linux (my platform), Michael> citing "resolver problems". I have a vague recollection of that. Michael> I haven't seen any discussion of this on this newsgroup yet. Michael> Considering that people who object to mlockall() usage on the Michael> grounds that it prevents running stock ntpd on limited-real-memory Michael> toasters have been given the cold shoulder, four years is a long Michael> time to deprive Linux users of its benefits. OK. Michael> Since ntpd does its resolving from a secondary process, it would Michael> seem that the problem could be avoided by moving the mlockall() Michael> call to after the "intres" process is forked. Except that until we get an async resolver library, there is still a very real possibility that somebody will use a runtime config command to add a new server which will fork a resolver process again... Michael> "resolver problems" probably wouldn't bite me, since I use IP Michael> addresses only in my configuration files, so that I can start ntpd Michael> before named. So it should be safe for me to hack the configure Michael> script so mlockall() is used anyway, right? Yes, and I'd be real curious to see how big a memory footprint ntpd takes for you before and after this change. Michael> Also, calling this a "Linux" problem is likely careless. I'd Michael> imagine the root of the incompatibility is probably in the GNU libc Michael> that is widely used with the Linux kernel. You are probably right, and the only places folks ever complained to me about the mlockall() problem was on linux-based systems, so that is what I called it. To change this would require a way to see if the kernel is using libc and test for it that way, instead of the current test which simply checks the type of the target host "triplet". 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. Please feel free to add questions or comments if you like. -- Harlan Stenn <st...@ntp.org> http://ntpforum.isc.org - be a member! _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
