From: Paulo Marques <pmarques@grupopie.com>
To: gilboad@gmail.com
Cc: Satyam Sharma <satyam@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Reduce __print_symbol/sprint_symbol stack usage.
Date: Fri, 21 Sep 2007 15:21:05 +0100 [thread overview]
Message-ID: <46F3D351.2090506@grupopie.com> (raw)
In-Reply-To: <1190378737.30016.15.camel@gilboa-home-dev.localdomain>
Gilboa Davara wrote:
> Hello Paulo,
Hi, Gilboa
> [snip]
>> [...]
>> if we change the interface from "print_symbol(fmt, addr)" to
>> "print_symbol(prefix, addr, int newline)" we can simply do:
>>
>> printk(prefix);
>> printk_symbol(addr);
>> if (newline)
>> printk("\n");
>>
>> where "printk_symbol" is a new function that does the same as
>> sprint_symbol, but does "printk" instead of "sprintf".
>>
>> This should reduce immensely the stack usage of print_symbol without the
>> need for locking.
>
> I fully agree.
> ... Further more, multiple printk_symbols should be combined into a
> single, multi-line printk transaction. (To prevent debug printk's from
> trashing a BUG() dump_stack).
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.
>> 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.
Kernel panics are quite rare and the information provided by the stack
dump is _extremely_ precious.
Even more, risking deadlocks caused by something that should only be
used to produce debug information is even worse.
>> 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.
--
Paulo Marques - www.grupopie.com
"God is love. Love is blind. Ray Charles is blind. Ray Charles is God."
next prev parent reply other threads:[~2007-09-21 14:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-15 11:35 [Minor patch] Reduce __print_symbol/sprint_symbol stack usage Gilboa Davara
2007-09-15 13:02 ` Satyam Sharma
2007-09-15 15:15 ` Gilboa Davara
2007-09-15 18:08 ` [PATCH] " Gilboa Davara
2007-09-19 1:00 ` Satyam Sharma
2007-09-19 14:25 ` Paulo Marques
2007-09-21 12:45 ` Gilboa Davara
2007-09-21 14:21 ` Paulo Marques [this message]
2007-09-21 14:57 ` Gilboa Davara
2007-09-21 14:56 ` Steven Rostedt
2007-09-21 15:47 ` Paulo Marques
2007-09-21 12:31 ` Gilboa Davara
2007-09-21 14:28 ` [PATCH] Reduce __print_symbol/sprint_symbol stack usage. (v3) Gilboa Davara
2007-09-21 16:02 ` Paulo Marques
2007-09-21 16:19 ` Gilboa Davara
2007-09-21 14:47 ` [Minor patch] Reduce __print_symbol/sprint_symbol stack usage Steven Rostedt
2007-09-21 14:53 ` Gilboa Davara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46F3D351.2090506@grupopie.com \
--to=pmarques@grupopie.com \
--cc=gilboad@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=satyam@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox