How much time in how much uptime? Which process are you looking at with
this accumulated time?
That's not an argument.
Even if runit's (or sysvinit's, or...) polling is completely
unnoticeable
- and on a desktop, to be fair, it definitely is - it doesn't mean that
polling is good.
Polling is evil for several reasons, the two most important of them
being
the following.
1. From a software engineering POV: software that depends on underlying
polling has to wait for the polling period to be sure its changes have
been taken into account. When you have a system A that polls, a system B
that depends on A and also polls in another place, etc., the polling
periods compound each other, and this can introduce significant delays.
I have met a real-life example of this at Google, of all places:
sending
a high-level command to a batch of servers takes several seconds,
sometimes several minutes - not because there's lot of CPU involved, or
high
network delays, but because Google's software stack is big, and most of
its
layers perform polling at some point (processing a message queue every
second, or every few seconds, instead of getting notified when a new
message arrives), and it adds up. Most of Google's high-level commands
(start a service on a cluster of servers, change routing tables to
direct
traffic somewhere else, etc.) spend a whole lot of time doing nothing.
Big scripts using high-level commands, such as automated software
rollouts,
sometimes take hours to complete, whereas the real work involved could
be
accomplished in 10-15 minutes tops; and software designed around polling
is the main culprit.
2. At the complete opposite end of the scale, from an energy
consumption
POV: you obviously will not notice that on a desktop, but on embedded
devices that are supposed to use energy sparingly (think set top boxes
in
"sleep" mode, battery-powered/handheld devices, etc.), every spurious
wake-up counts. Even if, as runit does, you only wake up once every 14
seconds, it means you pull the CPU out of sleep mode - it cannot sleep
for extended periods of time.
I have also met a real-life example of this, when I was working at
Sagemcom (a French manufacturer of embedded devices), making the base
system for an energy gateway (the thing that's supposed to collect and
report consumers' energy consumption; obviously, for such a task, it
should NOT use too much energy itself, else consumers will be angry and
have the right to be). I had spent a lot of time and energy trying to
convince the project leader that we should not use D-Bus, to no avail;
his argument was that D-Bus made communication easy with the Java part
(the proprietary application software was in Java). It was making *my*
life hell, but whatever, I could take it, I'm not a Java dev snowflake.
So I made a cool base system with no polling at all, with low-level
software reporting data to D-Bus, and shipped it to the Java people.
Later on, testing showed that the energy consumption was through the
roof,
and the board was brought back to us for analysis; what we discovered
was
that the chosen JVM implemented its D-Bus client by actually polling its
message queue every tenth of a second.
Yes, the thing was waking up 10 times per second. Really.
And, obviously, none of the tweaks we made were of any help: increasing
the polling period did not cut down energy consumption quite enough, but
it did cause significant delays in the handling of D-Bus data. I don't
know what became of the project, because I left the team at that time
(my part worked, so there was no reason for me to stay there, so they
put me on another project), but so far I haven't heard of a Sagemcom
energy gateway being deployed in people's homes.
When you're an init system, i.e. the lowest possible level for
user-space
software, and you *already* introduce polling, well, it doesn't bode
well
for the rest of your software stack. Your energy-saving device is
already
screwed, and automation that relies on runsvdir picking up a new service
is already eating an average 7 second delay. As a desktop user, you
obviously don't care; as a software architect, this makes me shake my
head.
Even systemd does better on that point.
--
Laurent
