add StartTimeMonotomic, StartTimeBootTime to per pid in /proc

starttime in /proc/$PID/stat is inaccurate by "clock tick" granularity. The kernel keeps better track os this exposes that in /prod/$PID/status as StartTimeMonotonic and StartTimeBootTime

---
 Documentation/filesystems/proc.txt |    6 +++++-
 fs/proc/array.c                    |    8 ++++++--
 2 files changed, 11 insertions(+), 3 deletions(-)

index 22d89aa3..6ed8001 100644
@@ -158,6 +158,8 @@ read the file /proc/PID/status:
   TracerPid:      0                                            (2.4)
   Uid:    501     501     501     501
   Gid:    100     100     100     100
+  StartTimeMonotonic:     3766799643
+  StartTimeBootTime:      3766799643
   FDSize: 256
   Groups: 100 14 16
   VmPeak:     5004 kB

@@ -202,7 +204,7 @@ asynchronous manner and the vaule may not be very precise. To see a precise
 snapshot of a moment, you can see /proc/<pid>/smaps file and scan page 

table.
It's slow but very precise.

-Table 1-2: Contents of the status files (as of 2.6.30-rc7) +Table 1-2: Contents of the status files (as of 3.13.0-rc3)

..............................................................................
Field Content
Name filename of the executable
@@ -215,6 +217,8 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7)
TracerPid PID of process tracing this process (0 if
not)
Uid Real, effective, saved set, and file
system UIDs
Gid Real, effective, saved set, and file
system GIDs

+ StartTimeMonotonic          Start time of process in nsec from CLOCK_MONOTONIC
+ StartTimeBootTime           Start time of process in nsec from CLOCK_BOOTTIME
  FDSize                      number of file descriptor slots currently 

allocated
Groups supplementary group list
VmPeak peak virtual memory size

index 1bd2077..34f4761 100644
@@ -188,7 +188,9 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns,
                "PPid:\t%d\n"
                "TracerPid:\t%d\n"
                "Uid:\t%d\t%d\t%d\t%d\n"
-               "Gid:\t%d\t%d\t%d\t%d\n",
+               "Gid:\t%d\t%d\t%d\t%d\n"
+               "StartTimeMonotonic:\t%lld\n"
+               "StartTimeBootTime:\t%lld\n",
                get_task_state(p),
                task_tgid_nr_ns(p, ns),
                task_numa_group_id(p),

@@ -201,7 +203,9 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns,
                from_kgid_munged(user_ns, cred->gid),
                from_kgid_munged(user_ns, cred->egid),
                from_kgid_munged(user_ns, cred->sgid),
-               from_kgid_munged(user_ns, cred->fsgid));
+               from_kgid_munged(user_ns, cred->fsgid),
+               timespec_to_ns(&p->start_time),
+               timespec_to_ns(&p->real_start_time));
 
        task_lock(p);
        if (p->files)

1.7.10.4

Why?

On request of Lennart Poettering for the Linux plumbers.

That's not an answer, so NAK then.

Well, the canonical way to expose clocks to userspace these days is with CLOCK_MONOTONIC, CLOCK_BOOTTIME, and so on. The starttime is currently exposed in a way that is made inaccurate by the clock tick in /proc/$PID/stat. Dan's patch simply unfucks that interface.

The process starttime is useful for a variety of things, like figuring out creation ordering of processes. Or it is useful to detect PID reuses in a somewhat reliable way. It is useful information to show the admin in "ps". Profilers like "bootchart" can use this information to plot when precisely specific process got started. From the outside it is often useful to see for how long a specific process has already been running, for accounting needs, and so on.

Note that Dan's patch doesn't add any new timestamp logic to the kernel, it just exposes the existing timestamps in a way to userspace that is more in line with the rest of timestamps exposed.

Lennart

That's actually factually incorrect. The start_time in task_stat is the exact same as used by Dan, its just that task_stat() decides to wreck it before printing it. Doesn't have anything to do with the actual clock tick.

OK, maybe. Changelog should have said so.

Does the one jiffy rounding really matter there? I doubt it, ps typically shows in second granularity.

Profilers have far better interfaces than /proc to get information from.

Yeah, Dan was also too lazy to explain the need, and had like 3 typoes in the inadequate changelog he had.

He also fails to explain why he needs the timestamp twice, as do you for that matter.

Does not inspire confidence.

Now please all untwist your panties and try and submit a proper patch.

Well, it's just annoying. Much of userspace uses CLOCK_MONOTONIC throughout all the local timestamping needs these days, however the jiffy rounding and the fact that "starttime" is based on CLOCK_BOOTTIME makes it hard to compare process timestamps currently with other timestamps...

That is true, but note that at least on Fedora taskstats and thing are actually disabled these days in the kernel, since they slow things down too much. The /proc interface is certainly much nicer there, since it relies on a the timestamping the kernel does anyway...

Well, I am mostly interesting int the monotonic timestamp. But given that the kernel keeps the boottime clock value as well, and already exposes it in a skewed way to userspace it looked like a natural choice to also expose that time in a clean way, while we are it...

Lennart

Lennart Poettering, Red Hat

Resubmitted with more explanation (and less typos). If you feel that having both CLOCK_MONOTONIC and CLOCK_BOOTTIME is really a sticking point I'd be ok to remove one as long as the other made it through, as one is much better than none.