incubator-mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles Reiss" <woggl...@gmail.com>
Subject Re: Review Request: Create utilities to collect information from the proc filesystem
Date Thu, 08 Dec 2011 00:19:42 GMT


> On 2011-12-07 21:10:13, Charles Reiss wrote:
> > src/monitoring/proc_utils.hpp, line 33
> > <https://reviews.apache.org/r/3050/diff/1/?file=62807#file62807line33>
> >
> >     Why strings? (and elsewhere)
> >
> 
> Alex Degtiar wrote:
>     I was deciding between using unsigned integers, something like the pid_t type, and
strings. I ultimately decided on strings because they supported special non-integer 'pids'
proc lets you query (i.e. "self"). This was convenient for testing.

I don't think there's any special "PID" other than "self", and that's easy replaced with getpid()
(which your test already needs).


> On 2011-12-07 21:10:13, Charles Reiss wrote:
> > src/monitoring/proc_utils.hpp, line 37
> > <https://reviews.apache.org/r/3050/diff/1/?file=62807#file62807line37>
> >
> >     Why milliseconds? libprocess uses seconds since some time, and I think USER_HZ
usually (often?) isn't 1000.
> 
> Alex Degtiar wrote:
>     Sam and I decided on milliseconds (since epoch when appropriate) for all measured
times because it was the granularity closest to the times in various sources, and having one
unit used consistently seemed cleaner. Would it make it more consistent with the rest of Mesos
if we scale it up to seconds?
>     
>     For reference, granularity of various times we used:
>     process start time (used for duration of initial read)- jiffies (4ms +/- depending
on system HZ)
>     boot time (used for start time to make it since epoch)- seconds
>     current time (used for duration) - nanoseconds/milliseconds since epoch (depends
on system)
>     cpu time (proc)- clock ticks (10ms +/- depending on system SC_CLK_TCK)
>     cpu time (lxc)- nanoseconds (unit returned in, not sure of actual granularity)
>     Period of measurement - potential lower bound on a single machine is probably in
the millisecond range.

Assuming process::Clock::now() can be counted on to be in time since the epoch (I don't actually
know if this is an API gaurentee), then I think you should have that replace getCurrentTime()
and thus use seconds since the epoch for everything.


- Charles


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3050/#review3712
-----------------------------------------------------------


On 2011-12-08 00:00:32, Alex Degtiar wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/3050/
> -----------------------------------------------------------
> 
> (Updated 2011-12-08 00:00:32)
> 
> 
> Review request for mesos.
> 
> 
> Summary
> -------
> 
> The first of several patches related to resource usage monitoring. This patch provides
a collection of utilities for use on Linux for reading stats from proc. It is used by both
the lxc and proc resource collectors.
> 
> 
> This addresses bug MESOS-89.
>     https://issues.apache.org/jira/browse/MESOS-89
> 
> 
> Diffs
> -----
> 
>   src/tests/Makefile.in ea943f7 
>   src/tests/proc_utils_tests.cpp PRE-CREATION 
>   src/monitoring/proc_utils.cpp PRE-CREATION 
>   src/Makefile.in 516f128 
>   src/monitoring/proc_utils.hpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/3050/diff
> 
> 
> Testing
> -------
> 
> Sanity tests have been written in src/tests/proc_utils_tests.cpp for all utility functions,
and functions have been tested ad hoc.
> 
> 
> Thanks,
> 
> Alex
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message