A little bit. The tldr; is that there are a lot of periodic activities including log rotation, automatic updates, time syncing, waking up to check if such things were currently needed, .... Those are generally nice (aside from automatic updates, which are sometimes good but I think usually more harmful than whatever they're fixing), but systemd doesn't know anything about what my userspace demands on the hardware are, and it's generally happy to hog system resources if it doesn't do so for long. For anything quasi-realtime, I can certainly hunt down and squash everything systemd is running at the wrong time, but in practice it's much easier to install something else, ensure no processes are running other than the ones I care about, and move those concerns to userspace.

> For anything quasi-realtime, I can certainly hunt down and squash everything systemd is running at the wrong time, but in practice it's much easier to install something else, ensure no processes are running other than the ones I care about, and move those concerns to userspace.

Should these issues be fixed by CPU/IO schedulers? Are there any systemd realtime tasks involved?

Now that the realtime patch is in mainline Linux, that approach might make more sense going forward. I don't think systemd has any meaningful realtime tasks by default. My current job has a different set of performance constraints (only need low latency something like 99% of the time, so systemd and noisy cloud neighbors and whatnot are fine), so I probably won't be looking at that part of the stack in any depth any time soon.

So pretty much, Gentoo+systemd and Gentoo-without-systemd aren't the same OS? One does auto updates, auto time syncing, auto logrotating etc, and apparently the other doesn't?

Or is the fact that systemd is the one doing it that much worse? Does systemd-timesyncd take more time than chronyd launched by some other init? I'd be surprised.