Thanks Vince, Will take a look at it. On Thu, Sep 19, 2013 at 9:49 AM, Vince Weaver <vincent.weaver@xxxxxxxxx> wrote: > On Thu, 19 Sep 2013, Dave Jones wrote: > >> It might be worth looking at Vince's perf fuzzer to see what he's done there >> for bisecting/generating test cases. > > my perf_fuzzer doesn't do anything that complicated. > > In its current setup it only has one thread, which occasionally forks off > a child but it always kills the child before forking off another. > > I find the run-to-run reproducibility of traces to be surprisingly > consistent when given the same random seed. Even hundreds of thousands > of syscalls in I can usually hit the same bugs at roughly the same > syscall count. > > I find this suprising because when perf events are involved nothing is > deterministic; if you are measuring things like cycles with overflow, the > cycle count is going to depend on what else is going on in the system, and > if your overflow handler consumes randomness (hard because rand() isn't > signal-handler safe, but possible with a few hacks) you'd expect things ro > diverge. > > As for bisecting, my major problem is dependent syscalls, something that > might not be as big an issue on trinity. The way perf_fuzzer is set up > you open an fd with perf_event_open(), then lots of other syscalls act on > the fd. So if your bisect happens to cut off the open of the fd, then > all subsequent dependent syscalls fail. I don't have a good automatic > solution to that, I've so far been placing the bisect points by hand and > just having the replayer be robust in cases where invalid dependent > syscalls appear in the trace. > > perf_fuzzer also has a somewhat human-readable log format, which wastes > disk space but makes it easier to do somewhat manual bisects using a text > editor. > > Vince > > > > > > -- To unsubscribe from this list: send the line "unsubscribe trinity" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
