> On Aug. 5, 2014, 12:30 a.m., Ian Downes wrote:
> > I'm not 100% clear from the description what this is doing - does it test 
> > correctness in anyway or is it really to be used under profiling to test 
> > the performance of the reaper? If it's the latter, then perhaps this should 
> > be standalone benchmark that steps through # of child pids?

This is meant for benchmarking; however, it is has dual purpose, and it wasn't 
clear how to integrate this type of benchmark.   Ideally, we'd want to 
continuously vary the pid count and, for this benchmark, the reap wait time.   
The wait time isn't programmatically exposed, but the question I have for you, 
is do we have a standard mechanism for exposing "endpoints" such as this ? 
Create a new internal interface ?

Finally, ideally, this test would make use of an external profiling api - so 
that we can start/stop the sampling periods at test entry.

I'm hoping GTEST has a lot of these hooks, but want to hear your ideas.


- Craig


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


On Aug. 4, 2014, 11:23 p.m., Craig Hansen-Sturm wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24270/
> -----------------------------------------------------------
> 
> (Updated Aug. 4, 2014, 11:23 p.m.)
> 
> 
> Review request for mesos and Ian Downes.
> 
> 
> Bugs: MESOS-1669
>     https://issues.apache.org/jira/browse/MESOS-1669
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> New test added which serves as a performance test for reaping. This test 
> forks N children (default value is 4), kills these children, and then uses 
> process::collect to collect all status results. This is a simple 
> generalization of the existing ChildProcess test, except that it is realtime 
> (as required for profiling), e.g., no clock manipulation is performed.  This 
> test is also useful for stressing the collect.hpp interfaces.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/src/tests/reap_tests.cpp a18d54c 
> 
> Diff: https://reviews.apache.org/r/24270/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Craig Hansen-Sturm
> 
>

Reply via email to