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:
pgpUBETuRiwgn.pgp
Description: PGP signature
