[riot-devel] Changing Cortex-M PendSV priority and handling in mutex.c

Kaspar Schleiser kaspar at schleiser.de
Sun Sep 16 15:04:45 CEST 2018

Hi Pekka,

On 9/15/18 10:02 AM, Nikander Pekka wrote:
> 1. Having PendSV at the same priority with the others, as today, causes instability with nRF52 SoftDevice

I encountered similar trouble when integrating the softdevice the first
time. Back then I used the SOFTDEVICE_PRESENT define to skip all RIOT
specific ISR priority meddling. Is that not working anymore?

> Exactly why PendPV at the same priority with other interrupts causes instability, I don't know.

That's the trouble with system-level blobs. I suggest asking Nordic
about it.

> 2. Having PendSV at the lowest priority increases performance
> The PendSV interrupt is designed to be used to perform the actual context switch just before returning from an interrupt to a normal thread context.  The basic idea is to switch the thread stack and context only when there are no more interrupts pending.  If there are still pending interrupts, running them may cause a higher priority thread to become ready to run.  If so, with the current RIOT practice, PendSV may first change the thread, then, without this thread getting any running time, the next pending interrupt may make another thread runnable and trigger another PendSV, causing another thread change.  The first thread change is wasted.

The reason pendsv has the same priority is that if had a lower one,
other ISRs would preempt it. That in turn messes up the scheduler,
unless it disables IRQs while it is running. It also increases ISR stack
Back then we decided that two ISR's occuring at the same time is a
corner case and not worth the price of the extra instructions for
disable/enable ISRs for *every* context switch. The actual number of
cycles spent in sched_run and saving/restoring thread state is <200
cycles. If less than every 100th ISR (<1%) happens to trigger a wasted
context switch, saving the two instructions for disable/reenable ISRs in
pendsv saves more instructions overall.

> Kaspar and Oleg, you seem to have changed this in #3511 [5].  Looking at #3450 [6], I think the main problem was that PendSV calls sched_run().  But, looking at isr_pendsv(), I don't see it calling sched_run().  Only isr_svc() does.

pendsv jumps into svc at it's end. ;)

> So, maybe it is time to revert that change?

We can certainly reconsider.

I think there's also the concept of ISR priority groups, with group
priority and subpriority within groups. The former control preemption,
the latter control the order of execution should the group priority be
the same.
Maybe this can be exploited, by putting all ISRs in the same group
priority but give pendsv the lowest subpriority.


More information about the devel mailing list