(Answering to Jan here, but the "you" in this message is generic - if
anything, it's directed more at Adrian.)
On 25/08/2016 11:56, Jan Bramkamp wrote:
> The skalibs library used by s6 to calculate the deadlines
> should use clock_gettime(CLOCK_MONOTONIC) on FreeBSD and
> as such shouldn't be affected by changes to the wall clock.
That's completely orthogonal to the system (iow it's not a linuxism).
Also, whether or not to use CLOCK_MONOTONIC is a difficult question, and
there are pros and cons for both answers. Not using CLOCK_MONOTONIC in the
general case is not an oversight; it's a carefully weighted decision, and
I'm aware it's not perfect - but using it would not be perfect either.
The main argument in favor of CLOCK_REALTIME is that skalibs uses TAI
internally, so as long as the system clock is reasonably accurate, time
computations are right - and CLOCK_REALTIME maintains a view of the
current time that is cohesive across the system, whereas CLOCK_MONOTONIC
is completely isolated. If the system clock is flailing around so much
that it has a noticeable impact on skarnet.org programs' operation, then
you likely have bigger problems.
The obvious exception is when you boot without a battery and have to
first set the time (most likely via NTP). In that case, yes, there will
be a big time jump. But the thing is: when the system clock does a
*forward* time jump, which is the case when you boot on Unix Epoch and
get the correct time later, it should not affect programs too much. After
the time jump, previously computed deadlines expire, so programs in an
event loop get a timeout; most of the time, it's harmless - they just
wake up once needlessly.
*Backwards* time jumps are much more of a problem, because they can cause
programs not timing out when you want them to, and I have run into trouble
because of that. But it was a bug in a script; there's no reason, ever, to
have a backwards time jump of more than one second - if your system clock
boots with an undefined value, you should set it to a fixed, arbitrary
value in the past early on in your init scripts, and that will avoid any
significant backwards time jumps later on.
There is a case where forward time jumps are a problem: if you are in an
init script that reports failure in case of a timeout, and the system clock
gets updated at that point, the init script may incorrectly report failure.
That can happen with some invocations of s6-rc, for instance. I am still
gathering data on the kind of things that can fail, in order to come up
with the best fix; so if you have precise examples where that initial
forward time jump is a real issue, please let me know.
About the number of processes s6 uses: yes, it uses a lot of processes,
and that has never been a problem for anyone. Processes are not a scarce
resource, and are a fundamental part of the Unix API with very useful
isolation properties, so I use them liberally. I have run s6, with a lot of
services, on a 32 MB machine for years, and have never run out of memory.
I haven't tried with 16 MB, but chances are s6 still isn't the limiting
factor if you run a s6-based system on a 16 MB machine.
The s6-supervise and s6-log programs, which are the ones you're likely to
find in abundance, are carefully designed to use as little private memory
as they can: an instance of s6-supervise should not be using more than
3 pages of private memory. That's 12 KB that cannot be shared per
s6-supervise process, plus whatever overhead is caused by your libc and
kernel. s6-log is a bit hungrier, about 6 or 7 pages tops in most cases,
because it's more complex and has to use heap memory to store log lines
and compiled regular expressions. That's still in the realm of "definitely
not the process you can accuse of using excessive memory".
If your system causes so much overhead per process that forking 50
processes for s6 (if you have that many services!) leaves a noticeable
dent in your available memory, then you should look at your system's
kernel and libc, which are clearly not lightweight enough to implement
a fully usable Unix API on resource-constrained devices.
--
Laurent
Received on Thu Aug 25 2016 - 11:30:44 UTC