Messages in this thread | | | Date | Sun, 11 Jan 2015 18:37:00 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH 3.19-rc2 v13 4/5] ARM: Add support for on-demand backtrace of other CPUs |
| |
On Fri, 9 Jan 2015 16:48:01 +0000 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Mon, Jan 05, 2015 at 10:19:25AM -0500, Steven Rostedt wrote: > > On Mon, 5 Jan 2015 14:54:58 +0000 > > Daniel Thompson <daniel.thompson@linaro.org> wrote: > > > +/* For reliability, we're prepared to waste bits here. */ > > > +static DECLARE_BITMAP(backtrace_mask, NR_CPUS) __read_mostly; > > > +static cpumask_t printtrace_mask; > > > + > > > +#define NMI_BUF_SIZE 4096 > > > + > > > +struct nmi_seq_buf { > > > + unsigned char buffer[NMI_BUF_SIZE]; > > > + struct seq_buf seq; > > > +}; > > Am I missing something or does this limit us to 4096 characters of > backtrace output per CPU? > > > This is the same code as in x86. I wonder if we should move the > > duplicate code into kernel/printk/ and have it compiled if the arch > > requests it (CONFIG_ARCH_WANT_NMI_PRINTK or something). That way we > > don't have 20 copies of the same nmi_vprintk() and later find that we > > need to change it, and have to change it in 20 different archs. > > Agreed, though I wonder about the buffer size. >
Have we had kernel back traces bigger than that? Since the stack size is limited to page size, it would seem dangerous if backtraces filled up a page size itself, as most function frames are bigger than the typical 60 bytes of data per line.
We could change that hard coded 4096 to PAGE_SIZE, for those archs with bigger pages.
Also, if the backtrace were to fill up that much. Most the pertinent data from a back trace is at the beginning of the trace. Seldom do we care about the top most callers (bottom of the output).
-- Steve
| |