On 10/14/14, 7:56 AM, Jiri Olsa wrote:
I read the rasd sources and realized we could poke this from another angle.. AFAIU the work the rasd does is following: - reads config file and opens configured tracepoints - reads samples comming from those tracepoints and displays/writes this data to the console/file - is there more?If I'm not missing anything, this is quite usefull/common usage pattern which would deserve new perf command. I can see the analogy with ftrace debugfs interface - choose/enable tracepoints - cat .../tracing/trace-pipe and there could be '-d' for the command to act as daemon.
Yes, this parallels a new use case on my end. Right now I am running perf record ... | perf script. With the tracepoints and filters involved it is a LOT of typing - and still collects more than is needed (I don't need MMAP events for example, only COMM events). I am leaning towards a new perf sub-command but from my scheduling timehist and daemon commands I know there is a lot of overhead that goes with that. A perf library with a stable API would make this a lot easier. (AFAIK the python bindings do not currently support opening events, it is mainly an analysis option.)
David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
