lkml.org 
[lkml]   [2003]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Port SquashFS to 2.6
Date
joern@wohnheim.fh-wedel.de wrote:
> On Sat, 19 July 2003 22:40:22 -0700, junkio@cox.net wrote:
> > >>>>> "DD" == David Dillow <dave@thedillows.org> writes:
> >
> > DD> Hmm, isn't that 4K allocated on the stack? Ouch.
> >
> > Ouch indeed. I was not looking for these things (I was just
> > porting not fixing). Thank you for pointing it out. Have a
> > couple of questions:
> >

Thanks for sending the 2.6 patch, due to work pressure, I have had very little
time to do these things recently. I am still, however, actively developing
squashfs (a 1.3 with some improvements will be released soon), and I'd prefer
to do code fixes myself.

> > - Would it be an acceptable alternative here to use blocking
> > kmalloc upon entry with matching kfree before leaving?
> >
> > - I would imagine that the acceptable stack usage for functions
> > would depend on where they are called and what they call.
> > Coulc you suggest a rule-of-thumb number for
> > address_space_operations.readpage (say, would 1kB be OK but
> > not 3kB?)
>
> As a rule of thumb, stay below 1k or you will get regular email from
> me. :)

I tend to allocate (small) buffers on the stack, when their size does not
seem to warrant either: a globally kmalloced buffer and consequent locking,
or a locally kmalloced buffer kfreed on exit from the function, which seems
wasteful. However, if 1K is the perceived wisdom on stack limits, then I will
alter the code.

Phillip


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.207 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site