== How I think you set up fair share scheduling under systemd

When I started writing this entry, I was going to say that systemd
automatically does fair share scheduling between and describe the
mechanisms that make that work. However, this turns out to be false
as far as I can see; systemd can easily do fair share scheduling,
but it doesn't do this by default.

The basic mechanics of fair share scheduling are straightforward.
If you put all of each user's processes into a separate cgroup [[it
happens automatically CGroupsPerUser]]. Well. Sort of. You see,
it's not good enough to put each user into a separate cgroup; you
have to make it a *CPU accounting* cgroup, and a memory accounting
cgroup, and so on. Systemd normally puts all processes for a single
user under a single cgroup, which you can see in eg _systemd-cgls_
output and by looking at _/sys/fs/cgroup/systemd/user.slice_, but
by default it doesn't enable any CPU or memory or IO accounting for
them. Without those enabled, the traditional Linux (and Unix)
behavior of 'every process for itself' still applies.

(You can still [[use _systemd-run_ to add your own limits here
SystemdForMemoryLimiting]], but I'm not quite sure how this works
out.)

Now, I haven't tested the following, but from reading the documentation
it seems that what you need to do to get fair share scheduling for
users is to enable _DefaultCPUAccounting_ and _DefaultBlockIOAccounting_
for all user units by creating an appropriate file in
_/etc/systemd/user.conf.d_, as covered in [[the systemd-user.conf
manpage
https://www.freedesktop.org/software/systemd/man/systemd-user.conf.html]]
and [[the systemd.resource-control manpage
https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html]].
You probably don't want to turn this on for system units, or at least
I wouldn't.

I don't think there's any point in turning on _DefaultMemoryAccounting_.
As far as I can see there is no kernel control that limits a cgroup's
share of RAM, just the total amount of RAM it can use, so cgroups
just can't enforce a fair share scheduling of RAM the way you can
for CPU time (unless I've overlooked something here).  Unfortunately,
missing fair share memory allocation definitely hurts the overall
usefulness of fair share scheduling; if you want to insure that no
user can take an 'unfair' share of the machine, it's often just as
important to limit RAM as CPU usage.

(Having discovered this memory limitation, I suspect that we won't
bother trying to enable fair share scheduling in our Ubuntu 16.04
installs.)