Kickstarter for buying and open source Amiga OS

[_ThEcRoW]

Since the majority of aros users, use it in x86 computers that have plentiful of power, why is a problem running an uae version that deals with the legacy software and give the rest of the os, the modern approach it need to implement smp?. Just a tought.

[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).

[itix]

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!

This is serious issue considering backwards compatibility. It is relevant only when running 68k binaries but using SysBase->ThisTask was always valid.

When writing new software or recompiling one (you are probably going to change ThisTask name to something else, right?) it is of course no issue.

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.

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?

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.

[psxphill]

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()'

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?

[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?

[psxphill]

* 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.

Is that how your forbid works? That the other cpu is only stopped when it's quantum expires? That would probably be a mistake, the first cpu might be trying to send a message to port that is on the other cpu (which currently requires a forbid to make sure the port doesn't disappear before you send the message).
 

* hardware IRQs are not longer delivered to CPU0 (which is the only core that can get hardware interrupts in this mode)

How is the second cpu task switching if it has no hardware interrupts? Is it controlled by the timer on cpu0?

[Ezrec]

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