jeremy@goop.org said:
> __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
There's nothing really fixable here.
> 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.
Yeah. I did get rid of the fd_set in sigio_handler, saving another 128 bytes.
Basically, UML is being screwed by the signal frame size.
> 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?).
Probably :-)
I don't really want to fiddle with that, because that will impose constraints
that will hurt responsiveness.
> Alternatively, could you just use a bigger stack?
*ding ding ding* We have a winner.
I'm going to allocate 4 pages instead of two, and either have three of them
available for the stack or have two available for the stack and the third
unmapped to protect the task structure.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:11 EST