On Fri, Jan 24, 2014 at 11:20:38AM +0100, Lennart Poettering wrote: > On Wed, 22.01.14 16:53, Peter Zijlstra (peterz@xxxxxxxxxxxxx) 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. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
