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
