Dave, I will make some tests today and will let you know once I have them. -Ildar On Thu, Sep 19, 2013 at 10:04 AM, Ildar Muslukhov <ildarm@xxxxxxxxxx> wrote: > 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
