From: Rolf Eike Beer <eike-kernel@sf-tec.de>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 2.4 2/2] cpqfc: Reduce stack usage of 2 functions
Date: Tue, 3 Jan 2006 15:28:39 +0100 [thread overview]
Message-ID: <200601031528.45529@bilbo.math.uni-mannheim.de> (raw)
In-Reply-To: <20060103115955.GA5288@dmt.cnet>
[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]
Am Dienstag, 3. Januar 2006 12:59 schrieben Sie:
>On Tue, Jan 03, 2006 at 02:51:46PM +0100, Rolf Eike Beer wrote:
>> Marcelo Tosatti wrote:
>> >On Mon, Jan 02, 2006 at 01:05:37PM +0100, Rolf Eike Beer wrote:
>> >> There are 2 function that do a lookup to the queue and buffer the
>> >> result. They only care about the first few bytes (to be exactly:
>> >> 38*sizeof(u32)), but they always pass a buffer of 2kB, which is located
>> >> on the stack.
>> >>
>> >> This patch reduces this buffer to the really needed size and changes
>> >> it's type to the correct target type. The rest of the queue is still
>> >> looked up but the result is ignored (as it would anyway).
>> >>
>> >> There are also some small cleanups for the other arguments of
>> >> CpqTsGetSFQEntry(), which is the lookup function.
>> >
>> >Is there an evidence that the gratuitous stack usage is causing problems
>> > with an 8kB stack?
>> >
>> >In other ways, this looks more like an optimization than a serious
>> > bugfix?
>>
>> I have no reports of this, but this proves nothing. But why waste one
>> quarter of the stack for nothing?
>
>My point is that v2.4 is into deep maintenance mode, which means that only
>critical bug fixes get merged into the tree.
Doesn't "ugly like hell" count as critical? *g*
>I'm not against the patch per se.
I've looked on it. Both of the functions with the 2k+ stack usage are called
from interrupt handler, one directly and one from the other. The stack usage
at this point is little above 4k plus everything that is needed to call the
interrupt handler. I don't know if this must be considered harmful.
Eike
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2006-01-03 14:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-02 11:44 [PATCH 2.4 0/2] Fix cpqfc Rolf Eike Beer
2006-01-02 11:56 ` [PATCH 2.4 1/2] Fix cpqfc::cpqfcTSPutLinkQue() Rolf Eike Beer
2006-01-02 12:05 ` [PATCH 2.4 2/2] cpqfc: Reduce stack usage of 2 functions Rolf Eike Beer
2006-01-03 10:29 ` Marcelo Tosatti
2006-01-03 13:51 ` Rolf Eike Beer
2006-01-03 11:59 ` Marcelo Tosatti
2006-01-03 14:28 ` Rolf Eike Beer [this message]
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=200601031528.45529@bilbo.math.uni-mannheim.de \
--to=eike-kernel@sf-tec.de \
--cc=linux-scsi@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
/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