Kickstarter for buying and open source Amiga OS

[Ezrec]

we will see. this is a research operating system for a reason.

Exactly. 'Silly-SMP' is a project to determine "What are the minimal changes needed to AROS to support 'full' SMP? Is it even possible?"

I had a bit of insight (misguided, and missing a lot of details, but I think pointing in the right direction) and I decided that, instead of just talking about possible design ideas, that "the code will prove out".

As of now, I can get a simulated dual-CPU system up on AROS hosted on Linux x86_64 (25% of the time - the other 75% of the time it crashes on boot).

Is it ready for prime time? No.
Is it ready for inclusion in AROS ABIv1? No.
Is it even ready for testers? No.

This is Research with a capital 'R'.

But that '25% of the time' _does_ show that a full SMP system on AROS is possible.

Lots of debugging, testing, more experimentation, etc etc. is needed.

But it is possible.

So far, the only 'user visible' changes are that some fields in
SysBase are NULL or zero, that previously had values:

* ThisTask is NULL (this is now per-CPU)
  - You should have been using FindTask(NULL)  anyway!
* Elapsed/IdleCount/DispCount is 0 (this is now per-CPU)
  - We (AROS) need to make an API to retrieve this per-CPU
* AttnResched/SysFlags changed
  - But you shouldn't have been using this anyway!

Strict priority scheduling is (currently) not strict at all, and I and Michal Schulz are experimenting with what that breaks in application-land, and if we really need to fix it.

The 'm68k changes' you see in the repository are for making sure unicore m68k still works - not for adding m68k multicore support.

But if someone *did* make a SMP m68k processor, there are MMU tricks that can be used to 'magically fix' the altered SysBase fields for pre-existing m68k programs - so compatibility is with AmigaOS 3.x is still possible.

For you Morphos/AmigsOS developers - if you would like to bounce ideas off of me with respect to adding SMP to your operating system of choice, feel free to contact me, or just silently watch my 'silly-smp' branch on gitorious.org

AROS (in my humble option) is here for the betterment of all AmigaOS-alike operating systems. We blaze the trail to the unexplored lands.

[Ezrec]

Some of the solutions, like being in a Forbid/Permit or Disable/Enable are likely to break. If you want those to continue working then Forbid will need to stop being a "don't let a task switch happen" to "stop all other cpu's and don't let a task switch happen", which is going to have a much higher cost.

Yes, that's the mechanism I'm currently experimenting with.

Forbid() is now 'stop all other CPUs but this one, and don't let task switch happen'
Disable() is now 'stop all other CPUs but this one, don't let task switches happen, AND stall any interrupts until Enable()'

Terribly bad for performance, but once we have a baseline for SMP, improvements can be made.

One idea I have is to make a variant of 'struct SignalSemaphore', and could be initialized to have semantics more like the Linux kernel's "spinlock()" and "spinlock_irqsafe()" class of functions.

That should allow us (AROS) to use that type of semaphore to protect datastructures instead of Disable()/Enable() and Forbid()/Permit() without the high cost of those global locks.

(Normal 'struct SignalSemaphore' won't help to protect things like the Exec Task lists, since it needs task switching (Wait() & Signal()) to do its magic).

[Ezrec]

I fear issue would be performance when handling SysBase access with MMU. You have to alter Sysbase->ThisTask but other fields like DeviceList must be exactly same on each CPU. Is it possible without slowing down the system too much?

DeviceList (and all other lists, including TaskWait and TaskReady) are still on the global SysBase - so no worries on those.

Another question is how are you handling interrupts? To my understanding handling interrupt will not halt other cores. It makes sense but is not compatible to the original implementation. It can break some software and possibly more than some drivers.

In the current SMP experiment, Disable() causes the following to occur:

* An implicit Forbid() occurs, and the Disable()ing CPU waits for all other cores' tasks to finish their Quantum, and wait for the Forbid() to release.
* hardware IRQs are not longer delivered to CPU0 (which is the only core that can get hardware interrupts in this mode)


Enable() does the opposite:

* An implicit Permit() occurs, enabling tasks to start running
* hardware IRQs are re-enabled to CPU0.

[Ezrec]

Do you restart the other CPU if Wait() is called in a Forbid() and then stop it again when the task that called Forbid() is rescheduled?

Yes, that is the intent.

[Ezrec]

Moderator: Sorry! I think this thread is RAPIDLY drifting off-topic?

Can break this into a new thread?

[Ezrec]

AROS SMP technical discussion continued at:
http://www.amiga.org/forums/showthread.php?p=745839