On Sun, Oct 08, 2000 at 11:21:01AM -0500, Jeff Dike wrote:
> Also, could you look at the stack pointer at each frame, to see if you are
> encountering any stack hogs in the generic kernel? In a different situation,
> I found devfs putting a 3K structure on the stack.
OK, top candidates on that stack trace are:
__restore(): 764
do_execve: 340
load_elf_binary: 324
segv: 180
sigio_handler: 176
load_script: 172
ext2_get_block: 160
set_signals: 156
block_read_full_page: 124
Looks like do_execve should be pretty easy to shrink: most of the stack
is in a local of type struct linux_binprm (308 bytes), which could be
kmalloced. I guess this would have some cost in speed, so I don't suppose
this could be a generic patch. Anyway, it isn't a solution in itself.
load_elf_binary is harder to deal with, since it just has lots of locals,
each relatively small.
segv is mostly a local struct siginfo (128 bytes).
sigio_handler is mostly an fd_set (128 bytes).
load_script has a local buffer for remembering the interpreter (128 bytes).
All up, there's about 660 bytes of stack which can be relatively easily
saved by converting locals to kmalloced memory, which still isn't enough
to solve the problem.
I haven't looked into UML's interrupt handling, but perhaps another approach
is to try and avoid recursive interrupts/exceptions and do some kind of
tail-recursion optimisation in the exception/signal handler. I don't
know if this would cause problems (deadlocks?).
Alternatively, could you just use a bigger stack?
J
PGP signature
