Why SMP configuration requires all the memory to be shared - details

Kernel
1

Hey there !
An SMP configuration requirement is that cores should share the same memory. I found a Joseph Julicher comment on this forum explaining why :

The SMP version of FreeRTOS schedules tasks to ALL cores in the system. That requires that the each core have access to the memory required by any task. Even the kernel task list must be shared between the cores. This requirement forces each R5 to have full access to ALL the memory.

I’m trying to figure out why more precisely. What I understand is : Even if a task is preempted on core 0 then “restarted” on core 1, its TCB and stack stay at the same place in memory. Thus, this same place should be accessible for both cores → Shared memory.

But I see a limit to this reason : We can force task object related data (task list, TCB, stacks…) to be in shared memory via static task creation, and put non-task object related data in some private memory. What will prevent the scheduler to work properly ? Let’s say… a global const used by several tasks ? Of course, these tasks using this const have to be pinned to the core associated at the mentioned private memory.

In fact there is no physical limit. But there is many “if” in what I’m saying. My thought is : the requirement “all shared memory” was chose so it’s not imposed to use static task creation and to pin tasks to a core. Moreover, if a task pinned to a core use data that shouldn’t be see by the other core, SMP configuration loose some interest, compared to AMP configuration, imo. I’ll finish by adding global var or const are maybe a tricky example, and I can’t see a more legitimate interest in private memory…

Am I missing some information or misunderstanding something ?

I precise that here I’m not trying to code or implement something. I wanna understand philosophy and choices made about SMP and AMP.

Thanks for help ! :slight_smile: :heart:

2

You are right, that if YOU are careful and only use memory tied to a single core in tasks that can only run on that core, then you can make the system work. If you are putting a task’s stack in “private” memory, then you can only create that task from that core, as creating a task needs access to the stack.

This is basically a case that if you understand the rules and how the system actually works, you know when you can break the “rules”.

Perhaps the bigger issue is that machines with private address space for cores, tend to be optimized to run most of they code from that private address space, so performance may not be to the level expected heavily using the shared address space.

1 Like
3

OK thanks for clarifying

As I’m officially still a student with not that much experience, I’ll don’t pretend I can break these rules without consequences. For now, let’s accept these justifications for this requirement.
I’m actually reviewing these rules and fundamentals by reading this. Really instructive ! :smiley: