[NOTES] Multi Core support

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome. This forum is NOT for support.
karlchansen
Posts: 5
Joined: Wed Jun 26, 2019 5:27 pm
Location: USA
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: [NOTES] Multi Core support

Postby karlchansen » Wed Feb 12, 2020 11:37 pm

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!

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: [NOTES] Multi Core support

Postby Giovanni » Thu Feb 13, 2020 7:19 pm

Hi,

Answered via PM.

Giovanni

User avatar
russian
Posts: 364
Joined: Mon Oct 29, 2012 3:17 am
Location: Jersey City, USA
Has thanked: 16 times
Been thanked: 14 times

Re: [NOTES] Multi Core support

Postby russian » Fri Jul 17, 2020 11:26 pm

russian wrote:ST Stellar MCU was announced only 11 months ago and it's complete silence since?

11+7=18 months now :(
http://rusefi.com/ - electronic fuel injection

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: [NOTES] Multi Core support

Postby Giovanni » Sat Jul 18, 2020 10:53 am

It is alive and well.

Giovanni

error414
Posts: 12
Joined: Fri Jan 22, 2021 12:11 am
Has thanked: 3 times

Re: [NOTES] Multi Core support

Postby error414 » Thu Feb 04, 2021 9:05 pm

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.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: [NOTES] Multi Core support

Postby Giovanni » Thu Feb 04, 2021 9:29 pm

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

abvg9
Posts: 1
Joined: Sat Apr 03, 2021 2:56 pm
Has thanked: 1 time

Re: [NOTES] Multi Core support

Postby abvg9 » Sat Apr 03, 2021 9:03 pm

Hi,

How is the development of this implementation going?

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: [NOTES] Multi Core support

Postby Giovanni » Sun Apr 04, 2021 2:28 am

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

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: [NOTES] Multi Core support

Postby Giovanni » Fri Apr 09, 2021 5:21 pm

Just a note, RT 7 in trunk is now SMP-able, it has been demonstrated on RP2040.

Giovanni

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: [NOTES] Multi Core support

Postby Giovanni » Sun Apr 11, 2021 3:57 pm

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


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 9 guests