xTaskNotify() taking way too long to switch task

Kernel
1

Hi,
I just did some quick measurements and noticed that from the moment a task of lower priority sends a xTaskNotify() notification to the only task of higher priority, it takes 44.4us on a 32bit PIC running at 200MHz. That is 8,880 cycles… (I corrected this as I initially thought it was 4 cycles / instruction) but just found out it is not because of pipelining) this unrealistically long…

I already had configUSE_PREEMPTION set to 1 so I assume adding taskYield() in the line immediately after it would not make any difference, just to be sure, is that correct?

I also did try adding adding taskYield() immediately after but it made no difference…

In order to make it switch immediately, what do I need to do?

Thank you
Rick

2

are you absolutely sure that no higher priority interrupt kicks in between the xTaskNotify() and the take? Best would be a deep trace; alternatively, can you use Tracealyzer?

3

The PIC32 context switch code is probably longer than that for any other port, but I’m not sure how many cycles it takes.

4

I checked and no other task has higher priority. All other tasks are priority 1 and there is only 1 task at priority 3.

What else could it be?

@rtel, you mention that PIC32 is probably longer. To me 8,880 cycles (I just updated the value mentioned in the OP which I incorrectly put to 2,200) for a context switch following a notification still seem way too much. But being a newbie that might be completely wrong. So just so I know, to get a feel for it, would it be generally possible for it to takes 8,880 instructions?

Thank you as always :slight_smile:
Rick

5

The code is here https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/MPLAB/PIC32MZ/port_asm.S#L152 and here https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/MPLAB/PIC32MZ/ISR_Support.h - note one cycle does not necessarily map to one instruction - some instructions may take multiple cycles.

6

I found what it was. There was a “fast” logging function which was supposed to be only few cycles but when looked at the code it turned out to be quite lengthy.

Thank you @rtel and @RAc as always! :slight_smile:
Rick