Messages in this thread | | | From | postmaster@lougher ... | Subject | Re: [PATCH] Port SquashFS to 2.6 | Date | Sun, 20 Jul 2003 11:16:18 +0100 |
| |
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/
| |