Re: [PATCH] Reduce __print_symbol/sprint_symbol stack usage.

[Gilboa Davara <gilboad@gmail.com>]

On Fri, 2007-09-21 at 15:21 +0100, Paulo Marques wrote:
> Gilboa Davara wrote:
> > Hello Paulo,
> 
> Hi, Gilboa
> 
> Usually the developer can separate the output by hand in the unlikely 
> case of simultaneous concurrent users of printk, so I don't think this 
> is really a big problem.

In general I agree, but as the number of cores increases dramatically,
hitting a warning/BUG/oops simultaneously on multiple cores (especially
during development) becomes more of a problem.

At least to me, It's not rare that when working on 8C or above machine,
an oops message becomes completely unreadable due to multiple debug
printks that trash the serial port output. 

Never the less, I do agree that this problem is more developer related
and should not hit an end user running a debug-free distribution kernel.

> 
> >> Of course this requires changing _all_ callers of print_symbol to use 
> >> the new interface, but these are less than 100 ;)
> > 
> > This is my first contribution to the Linux kernel. As such I rather
> > start small, and work my way up slowly. (Read: solve the immediate stack
> > over-run now, think about changing the symbol_display interface later)
> 
> Yes, but this is a sensitive area, so you can not just implement 
> something now that can cause regressions, and just fix it later.

True.
My aim is to create a patch that
A. Doesn't break the current interface/APIs while keeping the
patch/noise to a minimum.
B. Does not cause any type of regression.

> 
> Kernel panics are quite rare and the information provided by the stack 
> dump is _extremely_ precious.

I fully agree.

> 
> Even more, risking deadlocks caused by something that should only be 
> used to produce debug information is even worse.

Hopefully the latest patch moves one step further in removing your
concerns.

> 
> >> Comments?
> > 
> > I do agree that the current interface needs work.
> > 
> > ... But as I said, I rather start slowly and on small scale. (Though I
> > did find a rather problematic place to start at... ;))
> 
> Well, if we agree that this is the way to go, then the way to start 
> slowly would be to submit a patch that makes both interfaces available 
> for a while and changes the most stack-critical callers to the new 
> interface.
> 
> Then slowly keep submitting patches to change other callers 
> progressively until there are no more callers of the old interface. At 
> that point we can just drop it entirely.

If I cannot find a working solution that does meet my initial goals
(Minimal patch/no regression) I'll start from scratch - creating a new
trace call path.

- Gilboa