Previously we would treat a value of "0" as meaning "no-op", which lead
to quite a bit of confusion. The runtime-spec has been updated to make
the "pids.limit" value a pointer, and explicitly state that:

 * Values >= 0 should be treated as normal values; and
 * < 0 (usually -1) indicates "max".

In practice this means we should switch PidsLimit to an *int64. Luckily,
this is actually backwards-compatible with our previous JSON -- an old
value of "0" would be omitted from the output, which will now be parsed
as "nil". The handling by our cgroup code would be identical but the
latter now correctly reflects the guidance by the runtime-spec.

Signed-off-by: Aleksa Sarai <[email protected]>

Co-developed-by: Kir Kolyshkin <[email protected]>
Signed-off-by: Kir Kolyshkin <[email protected]>
Signed-off-by: Aleksa Sarai <[email protected]>

config: switch PidsLimit to *int64

Signed-off-by: jianghao65536 <[email protected]>
[cyphar: gofumpt systemd/dbus_test.go]
[cyphar: simplify retry loop to return from inside loop]
[cyphar: improve exponential backoff to be less aggressive]
[cyphar: improve parallel test]
Signed-off-by: Aleksa Sarai <[email protected]>

When the iocost controller is enabled it will emit statistics about its
usage in io.stat. Export this when available. This is a no-op when
iocost is not enabled.

There is a comment that we only expose data which directly maps to
cgroups v1. We're already breaking this by adding PSI metrics, so reword
this to just indicate that we currently don't recognize the other
fields.

Signed-off-by: Morten Hein Tiljeset <[email protected]>

fs2: add iocost statistics

systemd: retry when the dbus connection returns EAGAIN

First, we can reasonably expect the first three fields of
cpuacct.usage_all to be "cpu user system", even for future kernels,
and if we see something different, it doesn't make sense to continue.
So check that the header is as expected, and error out otherwise.

Second, if we have more than 3 values, and we've checked that the first
3 are as expected ("cpu user system"), we can safely ignore extra
columns. This fixes an issue on a custom kernel from Tencent, which
adds a few extra columns (see [1]), as reported in issue 46.

Add tests for both cases.

Fixes issue 46.

[1]: OpenCloudOS/TencentOS-kernel-0@0b66781
Reported-by: vimiix <[email protected]>
Signed-off-by: Kir Kolyshkin <[email protected]>

fs: fix/improve cpuacct.usage_all parsing