[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.
User avatar
FXCoder
Posts: 384
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 180 times
Been thanked: 130 times

Re: [NOTES] Multi Core support

Postby FXCoder » Mon Apr 12, 2021 2:20 am

Hi,
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.

So (if I understand well) the current chSysLock()/Unlock() would become the alias of chSysGlobalLock()/Unlock() functionality.
Depending on the current Port mode the API of "ChSys" locking would be...
1. Unicore mode - effectively just disable/enable IRQ
2. Multi-core non SMP - same as unicore just with two separate instances of OS running (issue with common peripheral use?)
3. Multi-core SMP - implements spinlock for chSysLock()/Unlock() and adds chSysLocalLock()/Unlock() (which just disables/enable IRQ)

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.

Agreed.
Using named lookup for instances would need to lock in the naming conventions. i.e. "ch" for core 0, "ch1" for core 1, "ch2" for core 2, etc.
Then think about thread registry which has backward compatibility... i.e. an instance named thread designation e.g. "ch:main" (or some other form of designation) TBD to allow threads to be referenced by affinity (or "any" if a specific instance is not specified).

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.

Agreed. Allowing threads to migrate cores (as per the Common Ready Queue topic) makes sense.
This leads to other discussion about load sharing, stopping cores, etc. (rather out of scope ATM).
Anyway also to be considered is the MAKE and .ld system. i.e. Main stack and exception stack for other cores should be described in MAKE?...
USE_PROCESS_STACKSIZE_C1
USE_EXCEPTIONS_STACKSIZE_C1

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.

Seems the muti-core/SMP port is very close to "good enough".
The addition of multi-core registry stuff to RT is wise to do ATM.
Then the RP2040 device peripheral set would need to be extended to allow applications to be implemented.
Minimal set would be to add SERIAL wrapper to SIO, add I2C and SPI and perhaps that should then be enough to enable some "real world" testing.
A priority list order thereafter might be USB, QSPI, WDG and then some fun stuff (PIO).
--
Bob

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 » Wed Apr 14, 2021 7:16 pm

Small update.

Now the registry is unified in SMP mode, it shows threads from both cores, in decoupled/single mode each instance has its own registry for its own threads. The shell has been updated to show the core where the thread is associated.

Other small changes:
- Now core_id_t is an "official" kernel type
- Variable ch_system is always present regardless the settings.
- OS instances now have a field core_id with the associated core.
- Threads always have an "owner" field pointing to their OS instance.
- Added a "system state" field to ch_system: uninitialised, initializing, running, halted states have been defined.
- Added an new API: chSysWaitSystemState(), it allows to synchronize extra cores with initialization performed on startup/main core (core zero in RP2040).
- TM calibration is now only performed by the startup/main core.

About core 1 start code, I will move it into the HAL and be configurable in mcuconf.h.

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 » Mon Apr 19, 2021 11:52 am

Just a curiosity: the current RT7 internal architecture, not fully detailed because it would be too large.

arch.png


Giovanni


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 23 guests