[BUG]every time add the “--profileTiling” will have error

[McbyX]

[McbyX]

this flag cannot use

[Xeratec]

Hi @McbyX
What network/test are you running? From the trace above, it appears to be a stack overflow. Please note that running in a profile node requires significantly more stack. I suggest you increase the core stack size.

[McbyX]

Thank you for your @Xeratec
I use this command：“python testRunner_tiled_siracusa_w_neureka.py -t Tests/Models/microLlama/microLlama64_parallel --neureka-wmem --profileTiling --l1=60000”，and i set “#define MAINSTACKSIZE 131072” and “#define SLAVESTACKSIZE 8192”，however，it still have error. i know siracusa has a 256KB L1, in my opinion ,131072(128KB)+8192(8KB)x8+60KB<256KB,my setting is reasonable.
Moreover,i check the "microLlama64_parallel.s",find the "addi sp sp -2032",this is the maximum stack space opened up.
if there is any problem with my understanding?

[Xeratec]

Thank you for your @Xeratec I use this command：python testRunner_tiled_siracusa_w_neureka.py -t Tests/Models/microLlama/microLlama64_parallel --neureka-wmem --profileTiling --l1=60000, and i set #define MAINSTACKSIZE 131072 and #define SLAVESTACKSIZE 8192, however, it still have error. i know siracusa has a 256KB L1, in my opinion ,131072(128KB)+8192(8KB)x8+60KB<256KB,my setting is reasonable. Moreover,i check the microLlama64_parallel.s, find the addi sp sp -2032, this is the maximum stack space opened up. if there is any problem with my understanding?

Well, addi sp sp -2032 does not say that much; it depends on the depth of your function calls. Additionally, 131072+8192x8+60000 is around 250.59 KiB, which might be too tight as we also have to store some static variables in L1. This should be shown if you enable the -v flag.

Can you please rerun the command with the -v flag and share the log? If this does not help, @runwangdl recently discovered a bug in the constraint formulation for the total memory size at a given memory level. Maybe you are experiencing an issue related to that. We plan to work on this and provide a fix soon.

And please use ` to mark code. Makes it easier to read ;)

[McbyX]

@Xeratec This error is too strange，how can i fix this？i ask AI for help，they cannot solve this.
Should I use the old version of the code? Does the previous version not have this issue?
I simply added a ‘--profileTiling’, and even if I make MAINSTACKSIZE larger, it still doesn't help.

[runwangdl]

This is caused by a section table overflow. The pi malloc table used to manage L1 got overflowed. You should check your section table, and your .text section is likely unusually large. Your original code was already very large, and adding the profiling code made the issue worse. The fix is to adjust the link.ld.

[McbyX]

@runwangdl
i found a very interesting thing, once i delete the ”printf("===== Profiling ${nodeName} =====\n")“in TilingPrototypes.py, and the Pre_kernel , Kernel , Post_kernel , Total information can successfully print out. (This is enough for me. ) Dose this mean ”printf("===== Profiling ${nodeName} =====\n")“ will consume a lot of section table?
However, i cannot find the definition of section table in "/app/install/pulp-sdk/rtos/pulpos/pulp/kernel/chips/siracusa/link.ld",i try to reduce the heap size ,i think reducing the heap size is equivalent to increasing the table size, but the error still exist, do i understand that right?

[runwangdl]

Because the heap of private bank 0 starts from the end of the last section in bank0 up to the linker-defined address 0x8000, if the .text segment becomes very large, private bank 0 may end up with no heap space at all. As a result, some variables allocated on the fc heap (e.g. pos_alloc_l1) become NULL. One possible solution is to avoid placing the FC heap in private bank 0 and instead allocate it in the shared bank, which can be done by modifying get_fc_alloc.