app_main slows by 40% when a task is running on APP CPU

[srjasz]

I am starting to use the second (APP CPU) processor on a -S3. I have created a task on APP CPU using xTaskCreatePinnedToCore() with affinity set to 1. The task is nothing more than a while loop that does nothing but loop. I have measured that the code running on PRO CPU in app_main() now runs 40% slower. I can't imagine that the scheduler takes 40% of the the processing time when a task on another core, with no dependencies, is created and running independently. I must be doing something wrong. Any help would be appreciated.
Thanks

[ESP_Sprite]

Depending on the SDK and your code, there might already be other things running on core 1, which are now severely CPU-starved.

[srjasz]

These are the stats before creating the task on core1. It isn't possible to know which core a task is running on, except for IDLE0 and IDLE1, it looks like 6% + 4% + <1% + 1% + <1% would not be able to starve either core.

main 42521437 3%
IDLE0 1078272197 91%
IDLE1 1119972898 95%
ipc1 20420805 1%
Tmr Svc 2251 <1%
ipc0 54322883 4%
esp_timer 2262 <1%


These are the stats after creating the task on core1. As above, there is no possible way anything is being starved.

mainProCpu 0 <1%
main 42527289 3%
IDLE0 1078266362 91%
IDLE1 1104904241 94%
ipc1 20421697 1%
Tmr Svc 2251 <1%
ipc0 54327750 4%
esp_timer 2276 <1%

[srjasz]

I found a way to add the core to the data and posted it below. It's pretty much what I thought but it is nice to have it verified.


main 0 42528371 3%
IDLE0 0 1078265259 91%
IDLE1 1 1119972879 95%
ipc1 1 20420751 1%
Tmr Svc 0 2257 <1%
ipc0 0 54324191 4%
esp_timer 0 2270 <1%


mainProCpu 1 0 <1%
main 0 42534411 3%
IDLE0 0 1078259211 91%
IDLE1 1 1104910674 94%
ipc1 1 20422291 1%
Tmr Svc 0 2257 <1%
ipc0 0 54328200 4%
esp_timer 0 2283 <1%

[srjasz]

I am doing multiplication on core 1 so it may be that the FPU is not being used. Looking into that.

[srjasz]

I found that it is not an FPU issue. I also found that everything runs slower no matter how low level. As an example adding 2 integers takes %50 longer.

[boarchuz]

Code? ESP-IDF version?

[ESP_Sprite]

Wondering if this is a memory contention issue, perhaps something like overlapping cache lines... can you put IRAM_ATTR on the function that does nothing and see if that changes things?

[srjasz]

esp-idf version 5.2
void core0(void) // created and running on core 0.
{
while(1){};
}
void core1(void) // created and running on core 1.
{
int i;
while(1)
{
i = i + 1;
}
}

If task core0() is created then task core1() will run slower.

[srjasz]

Thanks for the suggestion.

I tried IRAM_ATTR and it is much much better, but based on the jitter is see on the scope, not quite the same as if the task that does nothing is not created.

I went a step further and added code to the empty loop running on core 0 that does a I2C transfer which is a bit time consuming. It causes the code running on core 1 slow down even with IRAM_ATTR. In this case the amount of slowing is randomly variable so the amount of slowing is different each time through the loop. Behavior seems to be the same with or without IRAM_ATTR.