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
Signed-off-by: Dan Ballard <[email protected]>
---
Documentation/filesystems/proc.txt | 6 +++++-
fs/proc/array.c | 8 ++++++--
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index 22d89aa3..6ed8001 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -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
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 1bd2077..34f4761 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -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
On Tue, Jan 21, 2014 at 07:10:04AM -0800, Dan Ballard wrote:
> 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
>
Why?
On request of Lennart Poettering for the Linux plumbers.
On 14-01-22 07:53 AM, Peter Zijlstra wrote:
> On Tue, Jan 21, 2014 at 07:10:04AM -0800, Dan Ballard wrote:
>> 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
>>
> Why?
On Thu, Jan 23, 2014 at 06:52:03AM -0800, Dan Ballard wrote:
> On request of Lennart Poettering for the Linux plumbers.
That's not an answer, so NAK then.
On Wed, 22.01.14 16:53, Peter Zijlstra ([email protected]) wrote:
>
> On Tue, Jan 21, 2014 at 07:10:04AM -0800, Dan Ballard wrote:
> > 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
>
> Why?
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
On Fri, Jan 24, 2014 at 11:20:38AM +0100, Lennart Poettering wrote:
> On Wed, 22.01.14 16:53, Peter Zijlstra ([email protected]) wrote:
>
> >
> > On Tue, Jan 21, 2014 at 07:10:04AM -0800, Dan Ballard wrote:
> > > 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
> >
> > Why?
>
> 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.
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.
> 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.
OK, maybe. Changelog should have said so.
> It is useful information to show the admin in "ps".
Does the one jiffy rounding really matter there? I doubt it, ps
typically shows in second granularity.
> 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.
Profilers have far better interfaces than /proc to get information from.
> 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.
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.
On Fri, 24.01.14 12:32, Peter Zijlstra ([email protected]) wrote:
> > 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.
>
> OK, maybe. Changelog should have said so.
>
> > It is useful information to show the admin in "ps".
>
> Does the one jiffy rounding really matter there? I doubt it, ps
> typically shows in second granularity.
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...
> > 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.
>
> Profilers have far better interfaces than /proc to get information
> from.
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...
> > 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.
>
> 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.
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
>> 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.
>
> OK, maybe. Changelog should have said so.
>
> Yeah, Dan was also too lazy to explain the need, and had like 3 typoes
> in the inadequate changelog he had.
>
> Does not inspire confidence.
>
> Now please all untwist your panties and try and submit a proper patch.
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.