Re: TSC-low clock slow on WhiskeyLake i7-8565U (HP Spectre x360 13-ap0043dx)
On Mon, Sep 09, 2019 at 04:07:39PM -0400, Neel Chauhan wrote: > Hi, > > I recently got a HP Spectre x360 13-ap0043dx as a gift and by default > the clock runs slower on FreeBSD than Windows or Linux. Yes, I know the > ThinkPad is the best laptop for FreeBSD, but getting an X1 Carbon would > increase the price of the gift even more which couldn't be done. > > The kern.timecounter.hardware by default is set to TSC-low and the clock > is slow on the Spectre x360. Setting it to ACPI-slow resolves this > issue. > > The CPU is a Intel WhiskeyLake Core i7-8565U. > > Is the slow TSC-low an issue with WhiskeyLake in general or specifically > HP? Is it something else? > > I am considering writing a patch but before I write one, do other people > with WhiskeyLake laptops (or newer) have slow clocks (where one second > on the system is actually more in real life), or not. Start with providing full listing dmesg for verbose boot. Out of blue, try to set machdep.disable_tsc_calibration=1 in loader.conf and see if this improves things. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Building world with gcc9 not working
On Mon, Sep 9, 2019 at 11:05 PM Conrad Meyer wrote: > On Mon, Sep 9, 2019 at 8:25 PM Rebecca Cran wrote: > > > > Is building world with gcc still supported? I'm getting an error running > > the following: > > > > make XCC=/usr/local/bin/gcc9 XCXX=/usr/local/bin/g++9 buildworld > > Hi Rebecca, > > Aspirationally, yes. I did a successful CROSS_TOOLCHAIN=amd64-gcc > buildworld earlier this week. (It doesn't play well with binary pkg's > built with Clang, so I ended up replacing it with a Clang-built world > instead, but it compiled.) > > Unfortunately, amd64-xtoolchain-gcc is stuck on GCC 6.4.0, while > you're running the much more recent GCC9. I think GCC6.4.0 is more or > less expected to build world today, but I don't think many people are > building with GCC9. I would love for amd64-xtoolchain to move to a > newer version, but I don't know what is blocking that — it seems like > it should be straightforward. > I did a gcc8 build about a year or so ago, though I had to turn off Werror to complete the build... Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Building world with gcc9 not working
On Mon, Sep 9, 2019 at 8:25 PM Rebecca Cran wrote: > > Is building world with gcc still supported? I'm getting an error running > the following: > > make XCC=/usr/local/bin/gcc9 XCXX=/usr/local/bin/g++9 buildworld Hi Rebecca, Aspirationally, yes. I did a successful CROSS_TOOLCHAIN=amd64-gcc buildworld earlier this week. (It doesn't play well with binary pkg's built with Clang, so I ended up replacing it with a Clang-built world instead, but it compiled.) Unfortunately, amd64-xtoolchain-gcc is stuck on GCC 6.4.0, while you're running the much more recent GCC9. I think GCC6.4.0 is more or less expected to build world today, but I don't think many people are building with GCC9. I would love for amd64-xtoolchain to move to a newer version, but I don't know what is blocking that — it seems like it should be straightforward. Best regards, Conrad ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Building world with gcc9 not working
Is building world with gcc still supported? I'm getting an error running the following: make XCC=/usr/local/bin/gcc9 XCXX=/usr/local/bin/g++9 buildworld /usr/local/bin/gcc9 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DNO__SCCSID -DNO__RCSID -I/usr/src/lib/libc/include -I/usr/src/include -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/contrib/gdtoa -I/usr/src/contrib/libc-vis -DINET6 -I/usr/obj/usr/src/amd64.amd64/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libmd -I/usr/src/contrib/jemalloc/include -DMALLOC_PRODUCTION -I/usr/src/contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DWANT_HYPERV -DYP -DNS_CACHING -DSYMBOL_VERSIONING -g -MD -MF.depend.jemalloc_malloc_io.o -MTjemalloc_malloc_io.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing -Wno-error=uninitialized -Wno-error=unused-but-set-variable -Wno-error=unused-function -Wno-error=unused-value -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable -Wno-error=bool-operation -Wno-error=deprecated -Wno-error=expansion-to-defined -Wno-error=format-overflow -Wno-error=format-truncation -Wno-error=implicit-fallthrough -Wno-error=int-in-bool-context -Wno-error=memset-elt-size -Wno-error=noexcept-type -Wno-error=nonnull -Wno-error=pointer-compare -Wno-error=stringop-overflow -Wno-error=aggressive-loop-optimizations -Wno-error=cast-function-type -Wno-error=catch-value -Wno-error=multistatement-macros -Wno-error=restrict -Wno-error=sizeof-pointer-memaccess -Wno-error=stringop-truncation -I/usr/src/lib/libutil -I/usr/src/lib/msun/amd64 -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src -c jemalloc_malloc_io.c -o jemalloc_malloc_io.o jemalloc_malloc_io.c: In function '__je_malloc_vsnprintf': jemalloc_malloc_io.c:383:2: error: case label value exceeds maximum value for type [-Werror] 383 | case '?' | 0x80: \ | ^~~~ jemalloc_malloc_io.c:595:5: note: in expansion of macro 'GET_ARG_NUMERIC' 595 | GET_ARG_NUMERIC(val, 'p'); | ^~~ jemalloc_malloc_io.c:401:2: error: case label value exceeds maximum value for type [-Werror] 401 | case 'j' | 0x80: \ | ^~~~ jemalloc_malloc_io.c:595:5: note: in expansion of macro 'GET_ARG_NUMERIC' 595 | GET_ARG_NUMERIC(val, 'p'); | ^~~ jemalloc_malloc_io.c:389:2: error: case label value exceeds maximum value for type [-Werror] 389 | case 'l' | 0x80: \ | ^~~~ jemalloc_malloc_io.c:595:5: note: in expansion of macro 'GET_ARG_NUMERIC' 595 | GET_ARG_NUMERIC(val, 'p'); | ^~~ jemalloc_malloc_io.c:395:2: error: case label value exceeds maximum value for type [-Werror] 395 | case 'q' | 0x80: \ | ^~~~ jemalloc_malloc_io.c:595:5: note: in expansion of macro 'GET_ARG_NUMERIC' 595 | GET_ARG_NUMERIC(val, 'p'); | ^~~ jemalloc_malloc_io.c:410:2: error: case label value exceeds maximum value for type [-Werror] 410 | case 'z' | 0x80: \ | ^~~~ jemalloc_malloc_io.c:595:5: note: in expansion of macro 'GET_ARG_NUMERIC' 595 | GET_ARG_NUMERIC(val, 'p'); | ^~~ cc1: all warnings being treated as errors *** Error code 1 -- Rebecca Cran ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd segfaults on start
On Mon, Sep 9, 2019 at 3:12 PM Ian Lepore wrote: > On Mon, 2019-09-09 at 21:44 +0300, Konstantin Belousov wrote: > > On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote: > > > On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote: > > > > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > > > > > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin > > > > > > Belousov writes: > > > > > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert > > > > > > > wrote: > > > > > > > > [...] > > > > > > > > Doesn't locking this memory down also protect ntpd from OOM kills? > > > > If so that is a MUST preserve functionality, as IMHO killing ntpd > > > > on a box that has it configured is a total no win situation. > > > > > > > > > > Does it have that effect? I don't know. But I would argue that that's > > > a separate issue, and we should make that happen by adding > > > ntpd_oomprotect=YES to /etc/defaults/rc.conf > > > > Wiring process memory has no effect on OOM selection. More, because > > all potentially allocated pages are allocated for real after mlockall(), > > the size of the vmspace, as accounted by OOM, is the largest possible > > size from the whole lifetime. > > > > On the other hand, the code execution times are not predictable if the > > process's pages can be paged out. Under severe load next instruction > > might take several seconds or even minutes to start. It is quite unlike > > the scheduler delays. That introduces a jitter in the local time > > measurements and their usage as done in userspace. Wouldn't this affect > > the accuracy ? > > > > IMO, there is a large gap between "in theory, paging could cause > indeterminate delays in code execution" and "time will be inaccurate on > your system". If there were a delay in a part of the code where it > matters that amounted to "seconds or even minutes", what you'd end up > with is a measurement that would be discarded by the median filter as > an outlier. There would be some danger that if that kind of delay > happened for too many polling cycles in a row, you'd end up with no > usable measurements after a while and clock accuracy would suffer. > Sub-second delays would be more worriesome because they might not be > rejected as outliers. > > There are only a couple code paths in freebsd ntpd processing where a > paging (or scheduling) delay could cause measurement inaccuracy: > > - When stepping the clock, the code that runs between calling > clock_gettime() and calling clock_settime() to apply the step > adjustment to the clock. > > - When beginning an exchange with or replying to a peer, the code that > runs between obtaining system time for the outgoing Transmit Timestamp > and actually transmitting that packet. > > Stepping the clock typically only happens once at startup. The ntpd > code itself recognizes that this is a time-critical path (it has > comments to that effect) but unfortunately the code that runs is > scattered among several different .c files so it's hard to say what the > likelyhood is that code in the critical section will all be in the same > page (or be already-resident because other startup-time code faulted in > those pages). IMO, the right fix for this would be a kernel interface > that let you apply a step-delta to the clock with a single syscall > (perhaps as an extension to the existing ntp_adjtime() using a new mode > flag). > > On freebsd, the Receive timestamps are captured in the kernel and > delivered along with the packet to userland, and are retrieved by the > ntpd code from the SCM_BINTIME control message in the packet, so there > is no latency problem in the receive path. There isn't a corresponding > kernel mechanism for setting the outgoing timestamps, so whether it's > originating a request to a peer or replying to a request from a peer, > the transmit timestamp could be wrong due to: > > - paging delays > - scheduler delays > - network stack, outgoing queues, and driver delays > > So the primary vulnerability is on the transmit path between obtaining > system time and the packet leaving the system. A quick glance at that > code makes me think that most of the data being touched has already > been referenced pretty recently during the process of assembling the > outgoing packet, so it's unlikely that storing the timestamp into the > outgoing packet or the other bit of work that happens after that > triggers a pagein unless the system is pathologically overloaded. > Naturally, obtaining the timestamp and putting it into the packet is > one of the last things it does before sending, so the code path is > relatively short, but it's not clear to me whether it's likely or not > that the code involved all lives in the same page. Still, it's one of > the heavily exercised paths within ntpd, which should increase the odds > of the pages being resident because of recent use. > > So, I'm not disputing the point that a sufficiently overloaded system > can lead to an
Re: ntpd segfaults on start
On Mon, 2019-09-09 at 12:28 -0700, Cy Schubert wrote: > > > > On the other hand, the code execution times are not predictable if the > > process's pages can be paged out. Under severe load next instruction > > might take several seconds or even minutes to start. It is quite unlike > > the scheduler delays. That introduces a jitter in the local time > > measurements and their usage as done in userspace. Wouldn't this affect > > the accuracy ? > > IMO it would and would be unacceptable when used as a stratum N server or > with some OLTP or database applications. Locking a few megabytes is a small > cost. What I proposed was changing the default to not lock all of ntpd into memory, because I think that would work well for most users. Admins running stratum 1 or 2 servers are probably a bit more savvy about ntp configuration than the average user, and would use the rlimit command in ntp.conf. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd segfaults on start
On Mon, 2019-09-09 at 21:44 +0300, Konstantin Belousov wrote: > On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote: > > On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote: > > > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > > > > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin > > > > > Belousov writes: > > > > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert > > > > > > wrote: > > > > > > > [...] > > > > > > Doesn't locking this memory down also protect ntpd from OOM kills? > > > If so that is a MUST preserve functionality, as IMHO killing ntpd > > > on a box that has it configured is a total no win situation. > > > > > > > Does it have that effect? I don't know. But I would argue that that's > > a separate issue, and we should make that happen by adding > > ntpd_oomprotect=YES to /etc/defaults/rc.conf > > Wiring process memory has no effect on OOM selection. More, because > all potentially allocated pages are allocated for real after mlockall(), > the size of the vmspace, as accounted by OOM, is the largest possible > size from the whole lifetime. > > On the other hand, the code execution times are not predictable if the > process's pages can be paged out. Under severe load next instruction > might take several seconds or even minutes to start. It is quite unlike > the scheduler delays. That introduces a jitter in the local time > measurements and their usage as done in userspace. Wouldn't this affect > the accuracy ? > IMO, there is a large gap between "in theory, paging could cause indeterminate delays in code execution" and "time will be inaccurate on your system". If there were a delay in a part of the code where it matters that amounted to "seconds or even minutes", what you'd end up with is a measurement that would be discarded by the median filter as an outlier. There would be some danger that if that kind of delay happened for too many polling cycles in a row, you'd end up with no usable measurements after a while and clock accuracy would suffer. Sub-second delays would be more worriesome because they might not be rejected as outliers. There are only a couple code paths in freebsd ntpd processing where a paging (or scheduling) delay could cause measurement inaccuracy: - When stepping the clock, the code that runs between calling clock_gettime() and calling clock_settime() to apply the step adjustment to the clock. - When beginning an exchange with or replying to a peer, the code that runs between obtaining system time for the outgoing Transmit Timestamp and actually transmitting that packet. Stepping the clock typically only happens once at startup. The ntpd code itself recognizes that this is a time-critical path (it has comments to that effect) but unfortunately the code that runs is scattered among several different .c files so it's hard to say what the likelyhood is that code in the critical section will all be in the same page (or be already-resident because other startup-time code faulted in those pages). IMO, the right fix for this would be a kernel interface that let you apply a step-delta to the clock with a single syscall (perhaps as an extension to the existing ntp_adjtime() using a new mode flag). On freebsd, the Receive timestamps are captured in the kernel and delivered along with the packet to userland, and are retrieved by the ntpd code from the SCM_BINTIME control message in the packet, so there is no latency problem in the receive path. There isn't a corresponding kernel mechanism for setting the outgoing timestamps, so whether it's originating a request to a peer or replying to a request from a peer, the transmit timestamp could be wrong due to: - paging delays - scheduler delays - network stack, outgoing queues, and driver delays So the primary vulnerability is on the transmit path between obtaining system time and the packet leaving the system. A quick glance at that code makes me think that most of the data being touched has already been referenced pretty recently during the process of assembling the outgoing packet, so it's unlikely that storing the timestamp into the outgoing packet or the other bit of work that happens after that triggers a pagein unless the system is pathologically overloaded. Naturally, obtaining the timestamp and putting it into the packet is one of the last things it does before sending, so the code path is relatively short, but it's not clear to me whether it's likely or not that the code involved all lives in the same page. Still, it's one of the heavily exercised paths within ntpd, which should increase the odds of the pages being resident because of recent use. So, I'm not disputing the point that a sufficiently overloaded system can lead to an indeterminate delay between *any* two instructions executed in userland. What I've said above is more along the lines of considering the usual situation, not the most pathlogical one. In the most pathological cases, either
TSC-low clock slow on WhiskeyLake i7-8565U (HP Spectre x360 13-ap0043dx)
Hi, I recently got a HP Spectre x360 13-ap0043dx as a gift and by default the clock runs slower on FreeBSD than Windows or Linux. Yes, I know the ThinkPad is the best laptop for FreeBSD, but getting an X1 Carbon would increase the price of the gift even more which couldn't be done. The kern.timecounter.hardware by default is set to TSC-low and the clock is slow on the Spectre x360. Setting it to ACPI-slow resolves this issue. The CPU is a Intel WhiskeyLake Core i7-8565U. Is the slow TSC-low an issue with WhiskeyLake in general or specifically HP? Is it something else? I am considering writing a patch but before I write one, do other people with WhiskeyLake laptops (or newer) have slow clocks (where one second on the system is actually more in real life), or not. -Neel === https://www.neelc.org/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd segfaults on start
In message <20190909184446.gu2...@kib.kiev.ua>, Konstantin Belousov writes: > On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote: > > On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote: > > > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > > > > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin > > > > > Belousov writes: > > > > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote: > > > > > > > I've been able to set the memlock rlimit as low as 20 MB. The > > > > > > > issue is > > > > > > > letting it default to 0 which allows ntp to mlockall() > > > > > > > anything it wants. > > > > > > > ntpd on my sandbox is currently using 18 MB. > > > > > > > > > > > > Default stack size on amd64 is 512M, and default stack gap > > > > > > percentage is > > > > > > 3%. This means that the gap can be as large as ~17MB. If 3MB is > > > > > > enough > > > > > > for the stack of the main thread of ntpd, then fine. > > > > > > > > > > The default stack is 200K, which is also tuneable in ntp.conf. > > > > > > > > > > [...] > > > > > > > > I haven't seen anyone ask what I consider to be the crucial > > > > question > > > > yet: why are we locking ntpd into memory by default at all? > > > > > > > > I have seen two rationales for ntpd using mlockall() and > > > > setrlimit(): > > > > > > > >- There are claims that it improves timing performance. > > > > > > > >- Because ntpd is a daemon that can run for months at a time, > > > >setting limits on memory and stack growth can help detect and > > > >mitigate against memory leak problems in the daemon. > > > > > > Doesn't locking this memory down also protect ntpd from OOM kills? > > > If so that is a MUST preserve functionality, as IMHO killing ntpd > > > on a box that has it configured is a total no win situation. > > > > > > > Does it have that effect? I don't know. But I would argue that that's > > a separate issue, and we should make that happen by adding > > ntpd_oomprotect=YES to /etc/defaults/rc.conf > Wiring process memory has no effect on OOM selection. More, because > all potentially allocated pages are allocated for real after mlockall(), > the size of the vmspace, as accounted by OOM, is the largest possible > size from the whole lifetime. > > On the other hand, the code execution times are not predictable if the > process's pages can be paged out. Under severe load next instruction > might take several seconds or even minutes to start. It is quite unlike > the scheduler delays. That introduces a jitter in the local time > measurements and their usage as done in userspace. Wouldn't this affect > the accuracy ? IMO it would and would be unacceptable when used as a stratum N server or with some OLTP or database applications. Locking a few megabytes is a small cost. > > > > > Right now only syslogd has oomprotect set to YES by default. Maybe > > that's a good choice -- once we start declaring one daemon to be more > > important than others, you'll discover there's a whole back lot full of > > bikesheds that need painting. > > > > So maybe we should just document ntpd_oomprotect=YES in some more- > > prominent way. If we were to add a comment block to ntp.conf > > describing rlimit, that might be a good place to mention setting > > ntpd_oomprotect in rc.conf. > > > > -- Ian > > -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd segfaults on start
In message <66f80012757134b6317b673f9eeb24db66c996a2.ca...@freebsd.org>, Ian Le pore writes: > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin Belousov writes: > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote: > > > > I've been able to set the memlock rlimit as low as 20 MB. The issue is > > > > letting it default to 0 which allows ntp to mlockall() anything it want > s. > > > > ntpd on my sandbox is currently using 18 MB. > > > > > > Default stack size on amd64 is 512M, and default stack gap percentage is > > > 3%. This means that the gap can be as large as ~17MB. If 3MB is enough > > > for the stack of the main thread of ntpd, then fine. > > > > The default stack is 200K, which is also tuneable in ntp.conf. > > > > [...] > > I haven't seen anyone ask what I consider to be the crucial question > yet: why are we locking ntpd into memory by default at all? > > I have seen two rationales for ntpd using mlockall() and setrlimit(): > >- There are claims that it improves timing performance. > >- Because ntpd is a daemon that can run for months at a time, >setting limits on memory and stack growth can help detect and >mitigate against memory leak problems in the daemon. > > I am *highly* skeptical of claims that locking ntpd in memory will > improve timing performance on freebsd (to the point where I'm inclined > to dismiss them out of hand, but I'd be willing to look at any actual > evidence). > > The second point has at least some validity, but would be better > implemented (IMO) by decoupling the address space limit from the act of > locking down memory, and allowing configuration of RLIMIT_AS separately > from RLIMIT_MEMLOCK. If there's any interest in this, I could try to > put together a patchset and submit it upstream for that. Our upstream is already cc'd on this thread. diff --git a/usr.sbin/ntp/config.h b/usr.sbin/ntp/config.h index 56dbfedba6e..b26dd417885 100644 --- a/usr.sbin/ntp/config.h +++ b/usr.sbin/ntp/config.h @@ -287,7 +287,7 @@ #define DEFAULT_HZ 100 /* Default number of megabytes for RLIMIT_MEMLOCK */ -#define DFLT_RLIMIT_MEMLOCK 32 +#define DFLT_RLIMIT_MEMLOCK -1 /* Default number of 4k pages for RLIMIT_STACK */ #define DFLT_RLIMIT_STACK 50 But I'd wait for Harlan to weigh in on this. I agree with kib@ that this may introduce unwanted jitter. I'd also want to understand why this defaults to -1 for Linux only. > > I would propose that for freebsd, the autoconf-generated value for For the port but in base we control this directly. > DFLT_RLIMIT_MEMLOCK should be -1 to avoid calling setrlimit() and > mlockall() by default. Then in the ntp.conf we distribute we have a > section like: > ># To lock ntpd into memory, uncomment the following rlimit line. ># This should not be necessary on most systems, but may improve ># performance on heavily-loaded servers experiencing enough ># memory pressure to cause ntpd to be paged out. ># rlimit memlock stacksize > > Then we would need to come up with reasonable values for . I haven't had a chance to look at this in depth yet but I suspect that isn't in fact 32 as specified in config.h. It behaves as if this is set to 0 to mlockall() all it asks for. > > -- Ian -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd segfaults on start
On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote: > On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote: > > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > > > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin > > > > Belousov writes: > > > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote: > > > > > > I've been able to set the memlock rlimit as low as 20 MB. The > > > > > > issue is > > > > > > letting it default to 0 which allows ntp to mlockall() > > > > > > anything it wants. > > > > > > ntpd on my sandbox is currently using 18 MB. > > > > > > > > > > Default stack size on amd64 is 512M, and default stack gap > > > > > percentage is > > > > > 3%. This means that the gap can be as large as ~17MB. If 3MB is > > > > > enough > > > > > for the stack of the main thread of ntpd, then fine. > > > > > > > > The default stack is 200K, which is also tuneable in ntp.conf. > > > > > > > > [...] > > > > > > I haven't seen anyone ask what I consider to be the crucial > > > question > > > yet: why are we locking ntpd into memory by default at all? > > > > > > I have seen two rationales for ntpd using mlockall() and > > > setrlimit(): > > > > > >- There are claims that it improves timing performance. > > > > > >- Because ntpd is a daemon that can run for months at a time, > > >setting limits on memory and stack growth can help detect and > > >mitigate against memory leak problems in the daemon. > > > > Doesn't locking this memory down also protect ntpd from OOM kills? > > If so that is a MUST preserve functionality, as IMHO killing ntpd > > on a box that has it configured is a total no win situation. > > > > Does it have that effect? I don't know. But I would argue that that's > a separate issue, and we should make that happen by adding > ntpd_oomprotect=YES to /etc/defaults/rc.conf Wiring process memory has no effect on OOM selection. More, because all potentially allocated pages are allocated for real after mlockall(), the size of the vmspace, as accounted by OOM, is the largest possible size from the whole lifetime. On the other hand, the code execution times are not predictable if the process's pages can be paged out. Under severe load next instruction might take several seconds or even minutes to start. It is quite unlike the scheduler delays. That introduces a jitter in the local time measurements and their usage as done in userspace. Wouldn't this affect the accuracy ? > > Right now only syslogd has oomprotect set to YES by default. Maybe > that's a good choice -- once we start declaring one daemon to be more > important than others, you'll discover there's a whole back lot full of > bikesheds that need painting. > > So maybe we should just document ntpd_oomprotect=YES in some more- > prominent way. If we were to add a comment block to ntp.conf > describing rlimit, that might be a good place to mention setting > ntpd_oomprotect in rc.conf. > > -- Ian > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd segfaults on start
> On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote: > > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > > > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin > > > > Belousov writes: > > > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote: > > > > > > I've been able to set the memlock rlimit as low as 20 MB. The > > > > > > issue is > > > > > > letting it default to 0 which allows ntp to mlockall() > > > > > > anything it wants. > > > > > > ntpd on my sandbox is currently using 18 MB. > > > > > > > > > > Default stack size on amd64 is 512M, and default stack gap > > > > > percentage is > > > > > 3%. This means that the gap can be as large as ~17MB. If 3MB is > > > > > enough > > > > > for the stack of the main thread of ntpd, then fine. > > > > > > > > The default stack is 200K, which is also tuneable in ntp.conf. > > > > > > > > [...] > > > > > > I haven't seen anyone ask what I consider to be the crucial > > > question > > > yet: why are we locking ntpd into memory by default at all? > > > > > > I have seen two rationales for ntpd using mlockall() and > > > setrlimit(): > > > > > >- There are claims that it improves timing performance. > > > > > >- Because ntpd is a daemon that can run for months at a time, > > >setting limits on memory and stack growth can help detect and > > >mitigate against memory leak problems in the daemon. > > > > Doesn't locking this memory down also protect ntpd from OOM kills? > > If so that is a MUST preserve functionality, as IMHO killing ntpd > > on a box that has it configured is a total no win situation. > > > > Does it have that effect? I don't know. But I would argue that that's > a separate issue, and we should make that happen by adding > ntpd_oomprotect=YES to /etc/defaults/rc.conf > > Right now only syslogd has oomprotect set to YES by default. Maybe > that's a good choice -- once we start declaring one daemon to be more > important than others, you'll discover there's a whole back lot full of > bikesheds that need painting. > > So maybe we should just document ntpd_oomprotect=YES in some more- > prominent way. If we were to add a comment block to ntp.conf > describing rlimit, that might be a good place to mention setting > ntpd_oomprotect in rc.conf. > > -- Ian All very reasonable, thanks Ian. -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd segfaults on start
On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote: > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin > > > Belousov writes: > > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote: > > > > > I've been able to set the memlock rlimit as low as 20 MB. The > > > > > issue is > > > > > letting it default to 0 which allows ntp to mlockall() > > > > > anything it wants. > > > > > ntpd on my sandbox is currently using 18 MB. > > > > > > > > Default stack size on amd64 is 512M, and default stack gap > > > > percentage is > > > > 3%. This means that the gap can be as large as ~17MB. If 3MB is > > > > enough > > > > for the stack of the main thread of ntpd, then fine. > > > > > > The default stack is 200K, which is also tuneable in ntp.conf. > > > > > > [...] > > > > I haven't seen anyone ask what I consider to be the crucial > > question > > yet: why are we locking ntpd into memory by default at all? > > > > I have seen two rationales for ntpd using mlockall() and > > setrlimit(): > > > >- There are claims that it improves timing performance. > > > >- Because ntpd is a daemon that can run for months at a time, > >setting limits on memory and stack growth can help detect and > >mitigate against memory leak problems in the daemon. > > Doesn't locking this memory down also protect ntpd from OOM kills? > If so that is a MUST preserve functionality, as IMHO killing ntpd > on a box that has it configured is a total no win situation. > Does it have that effect? I don't know. But I would argue that that's a separate issue, and we should make that happen by adding ntpd_oomprotect=YES to /etc/defaults/rc.conf Right now only syslogd has oomprotect set to YES by default. Maybe that's a good choice -- once we start declaring one daemon to be more important than others, you'll discover there's a whole back lot full of bikesheds that need painting. So maybe we should just document ntpd_oomprotect=YES in some more- prominent way. If we were to add a comment block to ntp.conf describing rlimit, that might be a good place to mention setting ntpd_oomprotect in rc.conf. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd segfaults on start
> On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin Belousov writes: > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote: > > > > I've been able to set the memlock rlimit as low as 20 MB. The issue is > > > > letting it default to 0 which allows ntp to mlockall() anything it > > > > wants. > > > > ntpd on my sandbox is currently using 18 MB. > > > > > > Default stack size on amd64 is 512M, and default stack gap percentage is > > > 3%. This means that the gap can be as large as ~17MB. If 3MB is enough > > > for the stack of the main thread of ntpd, then fine. > > > > The default stack is 200K, which is also tuneable in ntp.conf. > > > > [...] > > I haven't seen anyone ask what I consider to be the crucial question > yet: why are we locking ntpd into memory by default at all? > > I have seen two rationales for ntpd using mlockall() and setrlimit(): > >- There are claims that it improves timing performance. > >- Because ntpd is a daemon that can run for months at a time, >setting limits on memory and stack growth can help detect and >mitigate against memory leak problems in the daemon. Doesn't locking this memory down also protect ntpd from OOM kills? If so that is a MUST preserve functionality, as IMHO killing ntpd on a box that has it configured is a total no win situation. Regards, Rod > I am *highly* skeptical of claims that locking ntpd in memory will > improve timing performance on freebsd (to the point where I'm inclined > to dismiss them out of hand, but I'd be willing to look at any actual > evidence). > > The second point has at least some validity, but would be better > implemented (IMO) by decoupling the address space limit from the act of > locking down memory, and allowing configuration of RLIMIT_AS separately > from RLIMIT_MEMLOCK. If there's any interest in this, I could try to > put together a patchset and submit it upstream for that. > > I would propose that for freebsd, the autoconf-generated value for > DFLT_RLIMIT_MEMLOCK should be -1 to avoid calling setrlimit() and > mlockall() by default. Then in the ntp.conf we distribute we have a > section like: > ># To lock ntpd into memory, uncomment the following rlimit line. ># This should not be necessary on most systems, but may improve ># performance on heavily-loaded servers experiencing enough ># memory pressure to cause ntpd to be paged out. ># rlimit memlock stacksize > > Then we would need to come up with reasonable values for . > > -- Ian > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd segfaults on start
On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin Belousov writes: > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote: > > > I've been able to set the memlock rlimit as low as 20 MB. The issue is > > > letting it default to 0 which allows ntp to mlockall() anything it wants. > > > ntpd on my sandbox is currently using 18 MB. > > > > Default stack size on amd64 is 512M, and default stack gap percentage is > > 3%. This means that the gap can be as large as ~17MB. If 3MB is enough > > for the stack of the main thread of ntpd, then fine. > > The default stack is 200K, which is also tuneable in ntp.conf. > > [...] I haven't seen anyone ask what I consider to be the crucial question yet: why are we locking ntpd into memory by default at all? I have seen two rationales for ntpd using mlockall() and setrlimit(): - There are claims that it improves timing performance. - Because ntpd is a daemon that can run for months at a time, setting limits on memory and stack growth can help detect and mitigate against memory leak problems in the daemon. I am *highly* skeptical of claims that locking ntpd in memory will improve timing performance on freebsd (to the point where I'm inclined to dismiss them out of hand, but I'd be willing to look at any actual evidence). The second point has at least some validity, but would be better implemented (IMO) by decoupling the address space limit from the act of locking down memory, and allowing configuration of RLIMIT_AS separately from RLIMIT_MEMLOCK. If there's any interest in this, I could try to put together a patchset and submit it upstream for that. I would propose that for freebsd, the autoconf-generated value for DFLT_RLIMIT_MEMLOCK should be -1 to avoid calling setrlimit() and mlockall() by default. Then in the ntp.conf we distribute we have a section like: # To lock ntpd into memory, uncomment the following rlimit line. # This should not be necessary on most systems, but may improve # performance on heavily-loaded servers experiencing enough # memory pressure to cause ntpd to be paged out. # rlimit memlock stacksize Then we would need to come up with reasonable values for . -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
