perf: Shutdown profiler/sampling on kpctl close
authorBarret Rhoden <brho@cs.berkeley.edu>
Tue, 14 Jun 2016 20:48:57 +0000 (16:48 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Fri, 17 Jun 2016 16:17:54 +0000 (12:17 -0400)
commitef1db1a7c0030f6d32e397ecda1150e42c8ea461
tree9068dd626579fba3a1e14cbdaefcd155fd3b45d5
parentf7cba7e51d9823100dd31b02c536f28f07a3dad8
perf: Shutdown profiler/sampling on kpctl close

There are two options for stopping the profiler: manually with a stop
command or by closing the FD.  We now support both.

The issue is a generic one that affects all of the Plan 9 devices, and the
root of the problem is how to deal with errors.  Let's use kprof as an
example.

Previously, to stop the profiler, you'd need to `echo stop > kpctl`.  This
works fine, so long as some program actually does this.  If for some reason
your program dies, e.g. perf crashes or exits with an error, it does not
stop the profiler.

If you do `perf record sleep 10 &; kill $PERF-PID`, then the profiler will
keep running.  (Side note: devarch's 'perf' file shuts down on close, so
we're only collecting mmap and comm events).  We're stuck waiting on an
event that will never occur.

The way to deal with this is to shutdown when the FD is closed.  This works
because the FD is implicitly closed when the process exits for any reason.
This also could work in a distributed system - eventually we can time out a
mount RPC and shut things down.  So by tying teardown into closing the FD,
we get fault tolerance with one mechanism.

The downside to using a close() as the signal to shutdown is you can no
longer easily control the device from the shell.  If you 'echo start >
kpctl`, it will start and then immediately stop when `echo` exits and its
FDs are closed.  That is the tradeoff.

This is not a new tradeoff in Plan 9.  The same thing happens with the IP
stack.  If you `cat /net/tcp/clone`, you'll create the conversation, but
the conversation closes as soon as `cat` exits.  I think the netlogger has
a similar issue (need to keep it open for logging to work).  Basically,
devices vary!

Ultimately, the power and value of the text based interface to these
devices isn't actually that it is scriptable, but that it is machine
independent.  Scripting is a nice convenience.

Oh, I kept the "stop" command around so that we can stop and start the
profiling without having to close the FD.  You want close() to work as an
option/failsafe, not as the only way to stop the device.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/drivers/dev/kprof.c
tools/profile/perf/perf.c
tools/profile/perf/perf_core.c