Quoting Mark Kettenis (mark.kette...@xs4all.nl):
> An accurate description would be that the percentage is actually the
> percentage of "DMA-reachable" physical memory the buffer cache may
> use. The minimum percentage is 5% and the maximum is 90%.
>
> But documenting it like that needs an explan
Quoting Mark Kettenis (mark.kette...@xs4all.nl):
> >
> > Hi. It turns out there is a hard cap which might be worth documenting.
>
> That isn't true.
I'm just informed the buffer cache limit is an amd64, arm64 and 32-bit
archs thing.
sparc64 appears to have no such limit. Do you know the details
Hi. It turns out there is a hard cap which might be worth documenting.
Index: lib/libc/sys/sysctl.2
===
RCS file: /cvs/src/lib/libc/sys/sysctl.2,v
retrieving revision 1.11
diff -u -p -r1.11 sysctl.2
--- lib/libc/sys/sysctl.2 30
Shouldn't /etc/rc check for executable bits in these two cases?
Index: etc/rc
===
RCS file: /var/cvsync/src/etc/rc,v
retrieving revision 1.437
diff -u -p -r1.437 rc
--- etc/rc 19 Jul 2014 21:27:16 - 1.437
+++ etc/rc
Some of us were discussing on IRC that ntpd (and other privsep daemons)
do not maintain their arguments in setproctitle, making invocations of
e.g. ntpd -s harder to verify.
This makes ntpd log that it was started with -s.
Index: ntpd.c
==
