Re: [PATCH 2/3][RFC] tracing: Add optional percpu buffers fortrace_printk()

[Steven Rostedt]

On Mon, 2011-10-10 at 13:08 +0200, Peter Zijlstra wrote:
> On Sat, 2011-10-08 at 13:02 -0400, Steven Rostedt wrote:
> > 
> > Ideally, using percpu buffers would be useful, but since trace_printk()
> > is only used in development, having per cpu buffers for something
> > never used is a waste of space. We could make this a compile option
> > but trace_printk() may also be used for developing modules, on a
> > distro kernels or for debugging at customer sites.
> > 
> > The approach taken here is to dynamically allocate percpu buffers
> > with a new tracing/options switch "trace_printk_percpu". It can
> > be allocated and freed at runtime, or "trace_printk_percpu" may also
> > be specified on the command line and it will be allocated at boot up.
> > 
> > This allows a developer to create percpu buffers for trace_printk()
> > on a running system, and also free them when not in used. 
> 
> Kill the old code, make tracing/events/trace_printk default to 0 and use
> enabling of that to allocate your per-cpu buffers.

This will make debugging some of my embedded boards difficult (the ones
where I have no way to add kernel command lines). If there's a problem
at boot up, I will have to modify the kernel to get this to print.

For those that don't know the tracing code, it will just simply break.

Unless you want me to keep the kconfig option that enables it
permanently. Then I could do this.

I also expect tglx to throw frozen sharks at me for "why doesn't
trace_printk() work anymore?!!!!"

-- Steve



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/