Re: boot tracing
* Sam Ben wrote: > On 07/12/2013 04:53 PM, Ingo Molnar wrote: > >* Borislav Petkov wrote: > > > >>On Fri, Jul 12, 2013 at 10:27:56AM +0200, Ingo Molnar wrote: > >>>Robert Richter and Boris Petkov are working on 'persistent events' > >>>support for perf, which will eventually allow boot time profiling - > >>>I'm not sure if the patches and the tooling support is ready enough > >>>yet for your purposes. > >>Nope, not yet but we're getting there. > >> > >>>Robert, Boris, the following workflow would be pretty intuitive: > >>> > >>> - kernel developer sets boot flag: perf=boot,freq=1khz,size=16MB > >>What does perf=boot mean? I assume boot tracing. > >In this case it would mean boot profiling - i.e. a cycles hardware-PMU > >event collecting into a perf trace buffer as usual. > > > >Essentially a 'perf record -a' work-alike, just one that gets activated as > >early as practical, and which would allow the profiling of memory > >initialization. > > > >Now, one extra complication here is that to be able to profile buddy > >allocator this persistent event would have to work before the buddy > >allocator is active :-/ So this sort of profiling would have to use > >memblock_alloc(). > > Could perf=boot be used to sample the performance of memblock subsystem? > I think the perf subsystem is too late to be initialized and monitor > this. Yes, that would be a useful facility as well, for things with many events were printk is not necessarily practical. Any tracepoint could be utilized. Thanks, Ingo -- 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/
Re: boot tracing
On 07/12/2013 04:53 PM, Ingo Molnar wrote: * Borislav Petkov wrote: On Fri, Jul 12, 2013 at 10:27:56AM +0200, Ingo Molnar wrote: Robert Richter and Boris Petkov are working on 'persistent events' support for perf, which will eventually allow boot time profiling - I'm not sure if the patches and the tooling support is ready enough yet for your purposes. Nope, not yet but we're getting there. Robert, Boris, the following workflow would be pretty intuitive: - kernel developer sets boot flag: perf=boot,freq=1khz,size=16MB What does perf=boot mean? I assume boot tracing. In this case it would mean boot profiling - i.e. a cycles hardware-PMU event collecting into a perf trace buffer as usual. Essentially a 'perf record -a' work-alike, just one that gets activated as early as practical, and which would allow the profiling of memory initialization. Now, one extra complication here is that to be able to profile buddy allocator this persistent event would have to work before the buddy allocator is active :-/ So this sort of profiling would have to use memblock_alloc(). Could perf=boot be used to sample the performance of memblock subsystem? I think the perf subsystem is too late to be initialized and monitor this. Just wanted to highlight this usecase, we might eventually want to support it. [ Note that this is different from boot tracing of one or more trace events - but it's a conceptually pretty close cousin. ] Thanks, Ingo -- 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/ -- 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/
Re: boot tracing
* Borislav Petkov wrote: > On Fri, Jul 12, 2013 at 10:27:56AM +0200, Ingo Molnar wrote: > > Robert Richter and Boris Petkov are working on 'persistent events' > > support for perf, which will eventually allow boot time profiling - > > I'm not sure if the patches and the tooling support is ready enough > > yet for your purposes. > > Nope, not yet but we're getting there. > > > Robert, Boris, the following workflow would be pretty intuitive: > > > > - kernel developer sets boot flag: perf=boot,freq=1khz,size=16MB > > What does perf=boot mean? I assume boot tracing. In this case it would mean boot profiling - i.e. a cycles hardware-PMU event collecting into a perf trace buffer as usual. Essentially a 'perf record -a' work-alike, just one that gets activated as early as practical, and which would allow the profiling of memory initialization. Now, one extra complication here is that to be able to profile buddy allocator this persistent event would have to work before the buddy allocator is active :-/ So this sort of profiling would have to use memblock_alloc(). Just wanted to highlight this usecase, we might eventually want to support it. [ Note that this is different from boot tracing of one or more trace events - but it's a conceptually pretty close cousin. ] Thanks, Ingo -- 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/
boot tracing
On Fri, Jul 12, 2013 at 10:27:56AM +0200, Ingo Molnar wrote: > Robert Richter and Boris Petkov are working on 'persistent events' > support for perf, which will eventually allow boot time profiling - > I'm not sure if the patches and the tooling support is ready enough > yet for your purposes. Nope, not yet but we're getting there. > Robert, Boris, the following workflow would be pretty intuitive: > > - kernel developer sets boot flag: perf=boot,freq=1khz,size=16MB What does perf=boot mean? I assume boot tracing. If so, does it mean we want to enable *all* tracepoints and collect whatever hits us? What makes more sense to me is to hijack what the function tracer does - i.e. simply collect all function calls. > - we'd get a single (cycles?) event running once the perf subsystem is up >and running, with a sampling frequency of 1 KHz, sending profiling >trace events to a sufficiently sized profiling buffer of 16 MB per >CPU. Right, what would those trace events be? > - once the system reaches SYSTEM_RUNNING, profiling is stopped either >automatically - or the user stops it via a new tooling command. Ok. > - the profiling buffer is extracted into a regular perf.data via a >special 'perf record' call or some other, new perf tooling >solution/variant. > >[ Alternatively the kernel could attempt to construct a 'virtual' > perf.data from the persistent buffer, available via /sys/debug or > elsewhere in /sys - just like the kernel constructs a 'virtual' > /proc/kcore, etc. That file could be copied or used directly. ] Yeah, that. > - from that point on this workflow joins the regular profiling workflow: >perf report, perf script et al can be used to analyze the resulting >boot profile. Agreed. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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/
