[SLOF] [PATCH slof] fdt: Avoid recursion when traversing tree
aik at ozlabs.ru
Fri Jul 17 21:02:34 AEST 2020
On 17/07/2020 20:28, Segher Boessenkool wrote:
> On Fri, Jul 17, 2020 at 07:39:53PM +1000, Alexey Kardashevskiy wrote:
>> Well, this too but it is just some waiting :)
>>> you seem to be talking about dysfunction of SLOF, which would be caused
>>> by stack exhaustion if I understand Segher's anwser correctly, right ?
>> Right. I am a bit surprised SLOF did not barf with "stack overflow" though.
> I do not know the current state of this well, so apply salt as needed...
> It is much too much overhead to check the stack pointer always
> (executing a single virtual machine insn is just a handful of real
> machine instructions!)
This all true but yet there is "ERROR: stack overflow in engine()" and I
saw these in the past, and there others. But I never got to understand
it completely their limits, Thomas would probably know.
> A traditional approach is to only check the
> stack in the outer interpreter loop (where you have to find every name
> that is used in the dictionary anyway, or parse numbers, or anything
> else that costs thousands of cycles *anyway*!)
> Many paflof configurations unmap the pages right above and below the
> stacks, to trap such things. That does let slight underflows through,
> because the top element is not usually actually stored on the stack.
> SLOF runs in real mode, so there are no guard pages, you can write to
> all RAM always.
> By default the interactive interpreter prints the stack depth at every
> prompt. This is very helpful while writing and testing code. And with
> the "test everything you write as soon as you write it" approach, most
> problems are avoided. Exceptions are capacity problems (like here), or
> anything else that cannot be tested for easily (hardware problems for
> So, perhaps this tree traversal code should call some "test the stack
> pointers and scream" word at strategic places? At the start of handling
> any subtree for example.
> (If some heavier routine is called for every node, you can put the test
> *there* instead, without making everything slow).
Making everything slow is perfectly fine for debugging SLOF. Thankfully
SLOF is not that complicated (real mode, 1 CPU, 1 device open at the
time) and normally a VM config is enough to reproduce the problem.
More information about the SLOF