Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Mutex/Priority Inheritance Performance on STM32F4-Discovery (Cortex-M4)

Posted by amtsarztlenin on June 24, 2015

Hello, I am currently experimenting with Mutexes in connection with FreeRTOS 8.2.0 on a Cortex-M4 based (168Mhz) STM32F4-Discovery board using the GNU C Compiler (gcc-arm) with an optimisation level of 2.

I am interested in the performance of Mutexes, in particular I want to know how fast they can solve a priority inversion problem. For measuring the time FreeRTOS needs to detect and fix priority inversion I have thought of the following scenario:

There are three tasks - LowPriorityTask (LP), MiddlePriorityTask (MP) and HighPriorityTask (HP) - and a mutex. MP and HP begin in a sleeping state. LP takes the mutex and wakes up HP which means that LP gets preempted by HP. HP then starts the time measurement, attempts to take the mutex, fails and enters a blocked state waiting for the mutex to get available. Therefore LP continues to execute, wakes up MP and would now theoretically be preempted by MP - this would result in slowing down the execution of HP. The RTOS detects this situation and raises the priority of LP so that it can continue executing until it gives the mutex. After this has happened HP can continue executing and take the mutex itself, after this the time measurement stops.

The same scenario in pseudocode:

~~~~~~~~~ function LowPriorityTask while true do TakeSemaphore WakeupHighPriorityTask WakeupMiddlePriorityTask GiveSemaphore end while end function ~~~~~~~~~

~~~~~~~~~ function MiddlePriorityTask while true do DO_SOMETHING end while end function ~~~~~~~~~

~~~~~~~~~ function HighPriorityTask while true do STARTMEASUREMENT TakeSemaphore END_MEASUREMENT end while end function
~~~~~~~~~

The time measurement is being done by toggling a GPIO Pin before and after the test sequence and checking the output on an oscilloscope.

Everything works as supposed, but I have noticed one thing that I do not understand:

If I increase the stack size of the three tasks, then the performance gets better. For example with a stack size of 128kB, the resulting time is constantly 31.3µs, but when the stack size is 512kB, then the resulting time is 30.8µs.

Does anyone have an idea why increasing the stack size of the tasks has a positive influence on the performance in this scenario? If wished, I can also supply the actual code that I used.

I am looking forward to reading your responses!


Mutex/Priority Inheritance Performance on STM32F4-Discovery (Cortex-M4)

Posted by rtel on June 24, 2015

I don't think the performance change will be to do with FreeRTOS, but the hardware. The stack size itself is not going to make any difference to FreeRTOS unless it is too small, but increasing the stack size will move the stacks around, and maybe you have hit an alignment that the hardware's pipeline or memory fetches prefer.

Regards.


Mutex/Priority Inheritance Performance on STM32F4-Discovery (Cortex-M4)

Posted by richard_damon on June 25, 2015

Actually, your time line is a bit off.

LP runs, takes mutex. LP starts HP. HP starts HP tries to take mutex, LP has priority raised to HP, and HP blocks LP starts MP Since LP has a temporary priority above MP, LP continues to execute. LP gives up the mutex, and has priority dropped back. HP gets the mutex and resumes. HP finishes (and presumably blocks for something, and gives back mutex for later) MP now can start and do its stuff.

As to why the timing improved, a possibility is that the extra stack size moves things a bit and changes cache performance (maybe moving two highly used items into different cache lines).


Mutex/Priority Inheritance Performance on STM32F4-Discovery (Cortex-M4)

Posted by amtsarztlenin on June 25, 2015

Thank you very much for your quick replies, these reasons seem very reasonable to me!


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists