> 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? > > Craig Hansen-Sturm wrote: > 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.
Just came to my mind that we already have a make bench call that runs BENCHMARK tests I believe. Can this test then fold under benchmark with a BENCHMARK tag as well? - Timothy ----------------------------------------------------------- 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 > >
