STM32MP1 --
Is there an existing STM32 I can load for support of the M4 on the STM32MP1?
Also @giovanni - I sent you a PM with more details on what drives my question. Thanks!
[NOTES] Multi Core support
-
karlchansen
- Posts: 5
- Joined: Wed Jun 26, 2019 5:27 pm
- Has thanked: 1 time
- Been thanked: 1 time
-
Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
-
Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: [NOTES] Multi Core support
Hi Giovanni,
I would like to ask you if multicore is supported curretly. I noticed mention about new RT7 branch, unfurtunately I don't see it in github. I bought new nucleo with H745, it's M7 - M4 multicore CPU.
I know that priority is new Pico board, just I would like to use chibios with multicore STM32.
Thank you very much for answer.
I would like to ask you if multicore is supported curretly. I noticed mention about new RT7 branch, unfurtunately I don't see it in github. I bought new nucleo with H745, it's M7 - M4 multicore CPU.
I know that priority is new Pico board, just I would like to use chibios with multicore STM32.
Thank you very much for answer.
-
Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: [NOTES] Multi Core support
Hi,
Asymmetric multi core support is not planned, the problem is that M0, M4, M7 etc have slightly different instruction sets, FPU and internal peripherals (requiring different compiler options) so it is not practical to make one OS run on mixed cores.
If you split your application in two distinct executables you can just run 2 instances of ChibiOS RT and/or NIL. The two applications can then communicate and synchronize using the HW semaphores and shared RAM areas.
Giovanni
Asymmetric multi core support is not planned, the problem is that M0, M4, M7 etc have slightly different instruction sets, FPU and internal peripherals (requiring different compiler options) so it is not practical to make one OS run on mixed cores.
If you split your application in two distinct executables you can just run 2 instances of ChibiOS RT and/or NIL. The two applications can then communicate and synchronize using the HW semaphores and shared RAM areas.
Giovanni
-
Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: [NOTES] Multi Core support
abvg9 wrote:Hi,
How is the development of this implementation going?
It is basically done: viewtopic.php?f=3&t=5800&start=40#p39683
Giovanni
-
Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: [NOTES] Multi Core support
Just a note, RT 7 in trunk is now SMP-able, it has been demonstrated on RP2040.
Giovanni
Giovanni
-
Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: [NOTES] Multi Core support
Hi,
Just sharing some ideas about SMP/multicore support:
Critical Sections
Currently there is a single spinlock used for all kernel structures, it is encapsulated in chSysLock()/Unlock(). This means that using a critical zone always takes the spinlock affecting the other core. This is less than optimal considering that there are kernel structures that are core-private, others are core-shared.
The ready list is shared.
The registry is private (but could become shared, see next points).
The virtual timers list is private, there is one list per core.
The trace buffer is private.
Statistics are private.
Optimizing this would mean having 2 "locked" states:
- Local lock, implements a critical section for the current core only.
- Global lock, implements a critical section for all cores.
The "S" and "I" functions would no more be sufficient, we would need to split those in "SG"/"IG" (global lock required) and "SL"/IL" (local lock sufficient), and the lock functions would become chSysGobalLock()/Unlock() and chSysLocalLock()/Unlock(), this would break compatibility for some APIs.
The above changes would minimize unneeded interactions between different cores improving scalability (note that currently 2 cores are rare, scalability to many cores is not urgent matter).
Registry
Currently we have one registry for each core, threads can only enumerate threads belonging to the same core. It would be nice to have a single registry able to enumerate all threads.
Affinity
It is already possible to associate threads to specific cores, it would be nice to be able to allocate working areas in "preferred" RAMs belonging to the various cores for performance optimization.
Common Ready Queue
Right now threads are statically assigned to specific cores, it would be possible to have a shared ready list for threads without affinity that can be picked up by any idling core. I would make this shared list reserved for low priority threads. This kind of handling would come at cost of reduced kernel performance, rescheduling would require checking 2 queues instead of just one. Global throughput would potentially increase.
The question is: should we release the current implementation or wait to implement all the possible enhancements? this could mean months of delays. Note that 20.x is very good and there is no need to rush IMHO.
Giovanni
Just sharing some ideas about SMP/multicore support:
Critical Sections
Currently there is a single spinlock used for all kernel structures, it is encapsulated in chSysLock()/Unlock(). This means that using a critical zone always takes the spinlock affecting the other core. This is less than optimal considering that there are kernel structures that are core-private, others are core-shared.
The ready list is shared.
The registry is private (but could become shared, see next points).
The virtual timers list is private, there is one list per core.
The trace buffer is private.
Statistics are private.
Optimizing this would mean having 2 "locked" states:
- Local lock, implements a critical section for the current core only.
- Global lock, implements a critical section for all cores.
The "S" and "I" functions would no more be sufficient, we would need to split those in "SG"/"IG" (global lock required) and "SL"/IL" (local lock sufficient), and the lock functions would become chSysGobalLock()/Unlock() and chSysLocalLock()/Unlock(), this would break compatibility for some APIs.
The above changes would minimize unneeded interactions between different cores improving scalability (note that currently 2 cores are rare, scalability to many cores is not urgent matter).
Registry
Currently we have one registry for each core, threads can only enumerate threads belonging to the same core. It would be nice to have a single registry able to enumerate all threads.
Affinity
It is already possible to associate threads to specific cores, it would be nice to be able to allocate working areas in "preferred" RAMs belonging to the various cores for performance optimization.
Common Ready Queue
Right now threads are statically assigned to specific cores, it would be possible to have a shared ready list for threads without affinity that can be picked up by any idling core. I would make this shared list reserved for low priority threads. This kind of handling would come at cost of reduced kernel performance, rescheduling would require checking 2 queues instead of just one. Global throughput would potentially increase.
The question is: should we release the current implementation or wait to implement all the possible enhancements? this could mean months of delays. Note that 20.x is very good and there is no need to rush IMHO.
Giovanni