Messages in this thread | | | Date | Tue, 6 Apr 2004 15:32:46 +0200 | Subject | Re: kernel stack challenge | From | Helge Hafting <> |
| |
On Mon, Apr 05, 2004 at 10:05:37AM -0700, Sergiy Lozovsky wrote: > > Consider rewriting your function to use allocated > > memory instead of stack, this isn't all that hard. > > I put LISP interpreter inside the Kernel - > http://vxe.quercitron.com > > It works, but it use a lot of stack memory. It's > impossible to rewrite it easily, though I'll > investigate why exactly it uses so much of stack > memory (though it's nature of LISP). There are no > serious kernel memory allocation (as of my interpreter > code review, only function calls; recursions in LISP > application itself are eliminated for sure), but I'll > trace stack usage more thouroughly. > Consider this. We're currently experimenting with a transition from 8k to 4k stacks on x86, and that is considered a very good thing. Allocating a single- page stack is easy, two (contigous) pages might fail.
So a bigger kernel stack is out.
As for rewriting code so it doesn't use stack - it _is_ easy, but it might be a lot of _work_.
The simple approach is to replace all (big) stack allocations with an explicit stack structure that you manages on the heap. There'll be more code, but it won't be slower because all the extra code is stuff that happen automatically with the hw stack. (I.e. stuff the compiler normally take care of.)
There is some more work if your interpreter also does deep recursion. It involves making one big function of those that do the recursion and manage the "calls" yourself with an array and a switch statement. Again, not particularly hard, but it could take some time to implement.
Helge Hafting - 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/
| |