-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/smp granular locks v4 #1154
base: main
Are you sure you want to change the base?
Feature/smp granular locks v4 #1154
Conversation
@chinglee-iot @aggarg This PR introduces the granular locks changes to the FreeRTOS kernel. Please have a look and we could have discussions/changes in this PR context. Thank you. cc: @ESP-Marius @Dazza0 |
Thank you for your contribution, I'll forward this request to the team. There are few error in the PR can you please try fixing them |
Hello @sudeep-mohanty, I am just following up if you had time to fix the build issues |
@rawalexe Yes! I shall work on the failures and would also do some refactoring for an easier review process. For now, I've put this PR in draft. |
0159a4a
to
5bf8c33
Compare
Hi @sudeep-mohanty, |
5bf8c33
to
9f8acc7
Compare
Hi @ActoryOu, I've made some updates which should fix the CI failures however I could not understand why the link-verifier action fails. Seems more like a script failure to me. So this action would still fail. If you have more information on what is causing it, could you let me know and I shall fix it. Thanks. |
c79962d
to
f50d476
Compare
Created a PR to fix the CI failure - FreeRTOS/FreeRTOS#1292 |
70eb466
to
edc1c98
Compare
Quality Gate passedIssues Measures |
c9eabd1
to
97a6841
Compare
97a6841
to
9975cb2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Early feedback for this PR.
Some NIT can be improved separately
- Review the SMP comment and use the following terms when granular lock feature has different implementation
- SMP with granular lock
- SMP without granular lock
For example,
#ifndef portRELEASE_TASK_LOCK
#if ( ( portUSING_GRANULAR_LOCKS == 1 ) || ( configNUMBER_OF_CORES == 1 ) )
#define portRELEASE_TASK_LOCK( xCoreID )
#else
#error portRELEASE_TASK_LOCK is required in SMP without granular lock feature
#endif
#endif /* portRELEASE_TASK_LOCK */
- egLOCK/UNLOCK and egENTER/EXIT_CRITICAL macros are used. I am favor of not using abbreviation "eg" here. We can consider to use full name. For example, using the following macros or other macros with full name.
#define event_groupLOCK
#define event_groupUNLOCK
#define event_groupENTER_CRITICAL
#define event_groupEXIT_CRITICAL
I will continue to review the following files and update my review suggestion again.
- queue.c
- stream_buffer.c
- tasks.c
9975cb2
to
7dae269
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update review suggestion for the following files
- queue.c
- event_groups.c
Overall review suggestions:
- portGET/RELEASE_SPINLOCK should be implemented with thread-safety.
- Consider to add coreID as parameter for the following port macros for performance consideration.
- portENTER_CRITICAL_DATA_GROUP
- portEXIT_CRITICAL_DATA_GROUP
- portENTER_CRITICAL_DATA_GROUP_FROM_ISR
- portEXIT_CRITICAL_DATA_GROUP_FROM_ISR
- The critical nesting count is used among all the data groups, including tasks.c. Can we move the portXXX_DATA_GROUP implementation back to kernel and use portXXX_CRITICAL_NESTING_COUNT in the implementation?
portDISABLE_INTERRUPTS(); | ||
|
||
/* Keep holding xTaskSpinlock to prevent tasks on other cores from accessing | ||
* the event group while it is suspended. */ | ||
portGET_SPINLOCK( portGET_CORE_ID(), &( pxEventBits->xTaskSpinlock ) ); | ||
|
||
portENABLE_INTERRUPTS(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
portGET_SPINLOCK
supposed to be thread safe then we can remove the disable/enable interrupts call here.
/* Keep holding xTaskSpinlock after unlocking the data group to prevent tasks | ||
* on other cores from accessing the queue while it is suspended. */ | ||
portGET_SPINLOCK( portGET_CORE_ID(), &( pxQueue->xTaskSpinlock ) ); | ||
|
||
queueEXIT_CRITICAL( pxQueue ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we adapt the following change to acquire task spinlock with interrupt enabled?
/* Keep holding xTaskSpinlock after unlocking the data group to prevent tasks | |
* on other cores from accessing the queue while it is suspended. */ | |
portGET_SPINLOCK( portGET_CORE_ID(), &( pxQueue->xTaskSpinlock ) ); | |
queueEXIT_CRITICAL( pxQueue ); | |
queueEXIT_CRITICAL( pxQueue ); | |
/* Keep holding xTaskSpinlock after unlocking the data group to prevent tasks | |
* on other cores from accessing the queue while it is suspended. */ | |
portGET_SPINLOCK( portGET_CORE_ID(), &( pxQueue->xTaskSpinlock ) ); |
vTaskPreemptionDisable( NULL ); | ||
|
||
/* Lock the stream buffer data group so that we can suspend the stream buffer atomically */ | ||
sbENTER_CRITICAL( pxStreamBuffer ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar reason like other module. portGET_SPINLOCK should be thread safe, then we can remove enter/exit critical section here.
…herit() xTaskPriorityInherit() is called inside a critical section from queue.c. This commit moves the critical section into xTaskPriorityInherit(). Co-authored-by: Sudeep Mohanty <[email protected]>
Changed xPreemptionDisable to be a count rather than a pdTRUE/pdFALSE. This allows nested calls to vTaskPreemptionEnable(), where a yield only occurs when xPreemptionDisable is 0. Co-authored-by: Sudeep Mohanty <[email protected]>
Adds the required checks for granular locking port macros. Port Config: - portUSING_GRANULAR_LOCKS to enable granular locks - portCRITICAL_NESTING_IN_TCB should be disabled Granular Locking Port Macros: - Spinlocks - portSPINLOCK_TYPE - portINIT_SPINLOCK( pxSpinlock ) - portINIT_SPINLOCK_STATIC - Locking - portGET_SPINLOCK() - portRELEASE_SPINLOCK() Co-authored-by: Sudeep Mohanty <[email protected]>
- Updated prvCheckForRunStateChange() for granular locks - Updated vTaskSuspendAll() and xTaskResumeAll() - Now holds the xTaskSpinlock during kernel suspension - Increments/decrements xPreemptionDisable. Only yields when 0, thus allowing for nested suspensions across different data groups Co-authored-by: Sudeep Mohanty <[email protected]>
Updated critical section macros with granular locks. Some tasks.c API relied on their callers to enter critical sections. This assumption no longer works under granular locking. Critical sections added to the following functions: - `vTaskInternalSetTimeOutState()` - `xTaskIncrementTick()` - `vTaskSwitchContext()` - `xTaskRemoveFromEventList()` - `vTaskInternalSetTimeOutState()` - `eTaskConfirmSleepModeStatus()` - `xTaskPriorityDisinherit()` - `pvTaskIncrementMutexHeldCount()` Added missing suspensions to the following functions: - `vTaskPlaceOnEventList()` - `vTaskPlaceOnUnorderedEventList()` - `vTaskPlaceOnEventListRestricted()` Fixed the locking in vTaskSwitchContext() vTaskSwitchContext() must aquire both kernel locks, viz., task lock and ISR lock. This is because, vTaskSwitchContext() can be called from either task context or ISR context. Also, vTaskSwitchContext() must not alter the interrupt state prematurely. Co-authored-by: Sudeep Mohanty <[email protected]>
Updated queue.c to use granular locking - Added xTaskSpinlock and xISRSpinlock - Replaced critical section macros with data group locking macros such as taskENTER/EXIT_CRITICAL() with queueENTER/EXIT_CRITICAL(). - Added prvLockQueueForTasks() and prvUnlockQueueForTasks() as the granular locking equivalents to prvLockQueue() and prvUnlockQueue() respectively Co-authored-by: Sudeep Mohanty <[email protected]>
Updated event_groups.c to use granular locking - Added xTaskSpinlock and xISRSpinlock - Replaced critical section macros with data group locking macros such as taskENTER/EXIT_CRITICAL() with egENTER/EXIT_CRITICAL(). - Added prvLockEventGroupForTasks() and prvUnlockEventGroupForTasks() to suspend the event group when executing non-deterministic code. - xEventGroupSetBits() and vEventGroupDelete() accesses the kernel data group directly. Thus, added vTaskSuspendAll()/xTaskResumeAll() to these fucntions. Co-authored-by: Sudeep Mohanty <[email protected]>
Updated stream_buffer.c to use granular locking - Added xTaskSpinlock and xISRSpinlock - Replaced critical section macros with data group locking macros such as taskENTER/EXIT_CRITICAL() with sbENTER/EXIT_CRITICAL(). - Added prvLockStreamBufferForTasks() and prvUnlockStreamBufferForTasks() to suspend the stream buffer when executing non-deterministic code. Co-authored-by: Sudeep Mohanty <[email protected]>
Updated timers.c to use granular locking - Added xTaskSpinlock and xISRSpinlock - Replaced critical section macros with data group locking macros such as taskENTER/EXIT_CRITICAL() with tmrENTER/EXIT_CRITICAL(). Co-authored-by: Sudeep Mohanty <[email protected]>
Co-authored-by: Sudeep Mohanty <[email protected]>
7dae269
to
4cf3837
Compare
Quality Gate passedIssues Measures |
This PR adds support for granular locking to the FreeRTOS kernel.
Description
Granular locking introduces the concept of having localized locks per kernel data group for SMP configuration. This method is an optional replacement of the existing kernel locks and is controlled by a new port layer configuration, viz.,
portUSING_GRANULAR_LOCKS
. More details about the approach can be found here.Test Steps
The implementation has been tested on Espressif SoC targets, viz., the ESP32 using the ESP-IDF framework.
1. Testing on an
esp32
targetesp32
, setup the ESP-IDF environment on your local machine. The steps to follow are listed in the Getting Started Guide.components/freertos/test_apps/freertos
where all the test cases are located.performance
subfolder at the same location.idf.py seet-target esp32
.menuconfig
options. To do this you must enter the command-idf.py menuconfig
->Component config
->FreeRTOS
->Kernel
->Run the Amazon SMP FreeRTOS kernel instead (FEATURE UNDER DEVELOPMENT)
. Save the configuration and exit the menuconfig.idf.py build flash monitor
.TODO
Checklist:
Related Issue
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.