On 2015/07/29 18:09, Alexander Shishkin wrote: > Takao Indoh <indou.ta...@jp.fujitsu.com> writes: > >> On 2015/07/29 15:08, Alexander Shishkin wrote: >>> Instead, we should be able to do use the existing perf functionality to >>> enable the system-wide tracing, so that it goes through the >> >> "existing driver" means PMU driver (perf_event_intel_pt.c)? > > Yes. > >> The feature of these patches is a sort of flight recorder. Once it >> starts, never stop, not export anything to user, it just captures data >> with minimum overhead in preparation for kernel panic. This usage is >> different from perf and therefore I'm not sure whether this feature can >> be implemented using perf infrastructure. > > Why not? There is an established infrastructure for in-kernel perf > events already, take a look at the nmi watchdog, for example.
Ok, I'm reading the code around perf_event_create_kernel_counter. It seems to work for my purpose, I'll try to update my patch with this. Thanks, Takao Indoh > >>> driver. Another thing to remember is that you'd also need some of the >>> sideband data (vm mappings, context switches) to be able to properly >>> decode the trace, which also can come from perf. And it'd also be much >>> less code. The only missing piece is the code that would allocate the >>> ring buffer for such events. >> >> The sideband data is needed if we want to reconstruct user program flow, >> but is it needed to reconstruct kernel panic path? > > You are not really interested in the panic path as much as events > leading up to the panic and those usually have context, which is much > easier to reconstruct with sideband info. Some of it you can reconstruct > by walking kernel's data structures, but that is not reliable after the > panic. > > Regards, > -- > Alex > -- 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/
