On Thu, Mar 30, 2006 at 01:34:07PM -0800, Linda Walsh wrote:
>...
> If I "doubled" my stack back to 8K, that would lower the "random
> probability" of hitting a stack limit, but right now, it seems like
> amount of stack "needed" is nearly guesswork. Sigh. Having my
> kernel fairly static and minimalistic (no unused modules; no loadable
> modules, etc) I might only "need" 3K.
Things like unused modules or loadable module support should have more
or less zero impact on stack usage.
> 1) It would be nice if a "stack usage" option could be turned on
> that would do some sort of run-time bounds checking that could
> display the max-stack used "so far" in "/proc".
The -rt kernel contains something like this.
> 2) How difficult would it be to place kernel stack in a "pageable" pool
> where the limit of valid data in a 4K page is only 3.5K - then
> when a kernel routine tries to exceed the stack boundary, it takes a
> page fault where a "note" could be logged that more stack was "needed",
> then automatically map another 4K page into the stack and return to
> interrupted routine.
>
> It sounds a bit strange -- the kernel having to call another part of
> the kernel to handle a pagefault within the kernel, but perhaps there
> could be another level of "partitioning" w/in kernel space that would
> allow the non-paging part of the kernel to be paged in/out in a similar
> way to user code.
>...
This has been discussed to death, and the consensus was that code
resulting in a too high stack usage should be fixed.
If you find any stack problems with 4k stacks and the automatically
enabled unit-at-a-time when using gcc 4.x in kernel 2.6.16-mm2, please
send a bug report.
Regarding unit-at-a-time with gcc 3.x, it works most time for most
people, but it's completely unsupported. If you want to use
unit-at-a-time on i386, please use gcc 4.x.
> -l
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
