Fix seconds reported by schedstat

[bitglue]

As explained further in the code comments, the previous implementation
was based on incorrect documentation and reported values 10000000 times
too large for the values in seconds.

Signed-off-by: Phil Frost [email protected]

[bitglue]

@discordianfish @pgier simple bugfix of recently added functionality, ready for review.

[bitglue]

@discordianfish @pgier bump

[bitglue]

@discordianfish @pgier rebump, easy bug fix, needs review.

[bitglue]

@discordianfish @pgier bump bump bump bump bump bump bump bump bump bump bump

[SuperQ]

Hrm, I really think we need some additional testing here to verify what's correct, and when exactly things changed in the kernel. We still support very old kernels, like RHEL 6 contains 2.6.32.

[SuperQ]

I ran a quick test, booting up a CentOS 6 box. It looks like it's been in NS for a long time.

[bjk@bjk-centos-6 ~]$ cat /proc/schedstat 
version 15
timestamp 4294786116
cpu0 0 0 65279 8841 37792 37792 80015632879 18335798709 56073
[bjk@bjk-centos-6 ~]$ uptime
 07:47:20 up 2 min,  1 user,  load average: 0.72, 0.38, 0.14
[bjk@bjk-centos-6 ~]$ uname -a
Linux bjk-centos-6 2.6.32-754.15.3.el6.x86_64 #1 SMP Tue Jun 18 16:25:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Field 7 indicates ~80.015 seconds of CPU time used with NS, and an absurd number if it were in Jiffies.

[bitglue]

The stats went from jiffies to ns in torvalds/linux@425e096

The log for that commit says "no code changes are caused by this patch." but I don't think that's true. Look at the implementation of sched_info_arrive(); the old implementation has

unsigned long now = jiffies, delta_jiffies = 0;

and the new implementation

unsigned long long now = sched_clock(), delta = 0;

sched_clock() returns time in nanoseconds.

This patch is part of the CFS implementation, which was first released in 2.6.23-rc1. Prior to that, stats were in jiffies. After that, stats were in ns.

Unfortunately, SCHEDSTAT_VERSION is set to 14 in either case. Between this, the commit message above ("no code changes"), and the documentation that was never updated, I guess this is a backwards-incompatible change which was introduced unintentionally.

So we don't have a straightforward way to know how to parse schedstats. But we could perhaps implement some heuristic, for example compare the counters to the timestamp field (which in all cases, does actually seem to be in jiffies) and if the counters are absurdly larger than timestamp, then assume they are in ns. If they are all less than timestamp, jiffies.

Or we can just forget about it, and people running kernels older than 2.6.23 can just have wrong metrics.

[SuperQ]

Well, good news, Go doesn't support older than 2.6.23, so we're safe to assume the nanosecond behavior. 😁

[SuperQ]

LGTM, thanks!

[pgier]

LGTM