On Wed, Sep 13, 2017 at 08:42:15AM -0600, Ross Zwisler wrote: > On Wed, Sep 13, 2017 at 09:47:29AM +1000, Dave Chinner wrote: > > <> > > > I think similar concerns exist with using perf, too.... > > I though that using perf addressed both concerns? > > > > > So what happens when the user is already tracing the test to > > > > find a bug and the test turns all their tracing off? > > By using perf we isolate our tracing from whatever other tracing is happening > in the system. So, unlike the case where we were messing with a system-wide > ftrace knob, we run perf on our executable, and someone else can run perf on > their executable, and they don't collide. Yes, you've addressed the "gets inteh way of other tracing concern, but it's doesn't address the "it's an ugly way to determine a feature is active" concerns. It also creates an implicit stable tracepoint out of whatever you are looking at. i.e. that tracepoint can't go away, nor can it change functionality once a userspace app depends on it's current semantics to function correctly. And.... > > > > Regardless of this screwing up developer bug triage, do we really > > > > want to add a dependency on kernel tracing into the test harness? > > Yep, you're right that this adds a dependency on perf. But unfortunately, > without using either perf or ftrace, I don't know of a way to detect whether > or not DAX is actually being used. Can you think of another way? ... if there isn't a programmatic interface to tell applications that DAX is in use, then perhaps we're missing a formal userspace API that we should have, yes? > I tried to do this correctly and just skip the test with _notrun > if perf isn't available on the host system. This is the same > thing that happens if you are missing other dependencies for a > test (some other command (chacl, getfattr, setfattr) not present, > quota tools not installed, required users not present, etc). Sure, but if we have user configurable functionality, then using something like ftrace/perf to discover if it's turned is indicative of a bigger problem. i.e. that the user can't tell if the functionality they turned on/off is actually active or not. That's a bug that needs fixing, not working around with ftrace/perf in xfstests... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
