On 2015/11/24 23:06, David Ahern wrote: > > So you are basically ignoring all samples until SIGUSR2 is received. That > means the resulting data file will have limited history of task events for > example. And for other events the quantity is random as to when the mmaps > were last scanned. > > Your cover letter mentioned my code "just makes some count when the signal > triggers perf sched, with no sample recording and has nothing to do with > perf.data". That is not correct. If you look at the perf-daemon code I > pointed you to it processes task events as they are received and saves the > last N-events after time sorting (limited by memory or time). When a signal > is received it processes the saved events and dumps them to stdout versus > writing a perf.data file. > > David >
Hi, David, Yes, I know that your sched daemon can store and print info when the signal triggers, however, what I mean 'makes some count' is: sched daemon parses and processes the events to extract the tracing info related with sched, rather than a general use of perf.data like "perf script", "perf report", "perf data convert --to-ctf", etc. And what I mean 'no sample recording and has nothing to do with perf.data' is: when perf receives a signal, sched daemon uses timehist_print_summary and timehist_pstree to record those tracing info related with sched to a new file rather than the raw perf event records in the perf.data. We can not use those files generated by sched daemon to enjoy the strong functions like how perf.data can be used in "perf script", "perf report", "perf data convert --to-ctf", etc. Sched daemon is good, but it is carefully designed for specific use of perf sched. In general case of perf record, with snapshot mode, we still want a perf.data as before. Your sched daemon concurrently does the work of storing and sched-parsing action for each signal trigger. To get a general style of perf.data, the sched-parsing semantic action may have to be removed. -- Thanks, Yunlong Song -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
