[Arm-netbook] severe systemd bugs (two of them)

[Luke Kenneth Casson Leighton]

On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla''
<valhalla-l at trueelena.org> wrote:

>> > Openrc is included in Debian.

> It was one of the candidates considered when deciding what init system
> to adopt, altought it had much less support than systemd or upstart (and
> I suspect it's even less tested than sysvinit).

 yeahh it was a pity it hadn't had as much mindshare: i've installed
it by default on the parabola gnu/linux-libre eoma68-a20 images and,
whilst it works well, it feels a little... odd.  perhaps that's down
to being unfamiliar with it, or that parabola / archlinux requires
that if you install e.g. openssh you have to remember to install
openssh-openrc and then also run a manual command to make sure it's
enabled at boot time (pacman lacks the postinst functionality of dpkg,
and archlinux itself seems to lack the concept of setting up "default
configured behaviour" for services, leaving that to the user
themself).

 one good thing: i wasn't aware that openrc could be parallelised:
it's as simple as adding rc_parallel="YES" to /etc/openrc.conf which i
will try out very shortly.

 back when the openmoko came out, you remember you bought one phil,
and told me that it was terribly unresponsive?  they used an ARM9
processor, which has a very poorly-designed 1st level cache.  on the
ARM9, thread/process context-switching results in COMPLETELY throwing
away the contents of the 1st level cache.

 so any context-switch - x11, d-bus, parallel startup, whatever -
resulted in performance that was last seen when sysvinit was initially
designed, because it *was* designed [N decades ago] to start services
*in series* so that context-switching could be minimised as much as
possible.

 unfortunately, developers who primarily use x86/amd64 forget that it
is only intel / AMD processors that have heavily-optimised context
switching: hyperthreading, 4 or more cores / hardware-threads
(usually, these days), 1st level cache that's often larger than the
2nd level cache of embedded processors and so on...

 ... so they design software that really only works well on x86.  i
remember around 2004 running opie / familiar on 600mhz Intel ARM PXA
270 processors (before PXA was sold to marvell) and the boot time was
often in the *TWO MINUTE* range.  god only knows what would happen if
systemd was deployed on such processors.

 systemd unfortunately makes heavy use of d-bus for message-passing.
unlike most client-server RPC architectures, d-bus acts as an
INTERMEDIARY.  that makes for DOUBLE context-switching.  client SWITCH
d-bus-as-intermediary SWITCH server.  for *each part of a round-trip*.
that means *FOUR* context-switches for a simple "request-response" as
opposed to just two for any other client-server RPC architecture.

 the heavy usage of d-bus for the openmoko OS basically was part of
what killed the project.  it would not surprise me at all to find that
d-bus is similarly slowing systemd down when compared to other init
systems.

 anyway i'll dig the parabola microsd card out again, switch to
parallel openrc and boot it up.  it might be a bit much for the A20 to
handle, but we'll soon see.

l.