AROS SMP Research: Technical Discussion

[Ezrec]

Continued from thread: http://www.amiga.org/forums/showthread.php?t=65748

[Ezrec]

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

 
In that case, you (the programmer) need to update your code anyway, since you could have gotten pre-empted right before the SendMsg()/Signal() and lost that port, even on AmigaOS 3.x

 

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

That is architecture specific. On the 'unix hosted' AROS environment, CPU0 proxies the timer scheduling interrupt for the other CPUs.

On pc-x86, we will probably use the Local APIC timers, and an IPI signal to tell the cores to 'please stop running for a bit, until I tell you otherwise'.

[Ezrec]

You need a forbid round the find/sendmsg, but you won't want the forbid to wait for all cpu's to finish their quantum. When the forbid happens the other cpu's need to stop what they are doing immediately.

I think you're misunderstanding: the Forbid() doesn't return until the other CPUs have stopped.

[Ezrec]

I think you're misunderstanding: the Forbid() doesn't return until the other CPUs have stopped.

And I think *I* have something wrong. Michal Shulz did some rough performance calculations, and even though my method (wait for quantum to expire) is semantically correct, the performance penalty is terrifying.

I'll experiment with signalling the other cores to stop immediately, and see how that works out.

[Ezrec]

Yeah that was my point. Making forbid wait for the other cpus will mean that these four lines of code will take over 1 task quantum.

Ok, looks like we're on the same page now.

Michal's planning on using IPI to signal the other CPUs to stop (on x86 SMP, there's isn't some "magic register" you can use to stop other CPUs, you have to ask them nicely), but it's a lot faster than waiting until they reach a Switch()/Dispatch() point.

[Ezrec]

Do you think the time the cpu is suspended not counting towards the quantum make sense? Otherwise the fairness will depend on what is running on the other cpu's & you could get one task that is permanently starved in pathological cases.

Right now, suspended CPUs do not have their Elapsed updated when they are suspended, so they should not be starved.

[Ezrec]

Even if it can be made to work, it's going to serialise the CPUs so much that that's no point having multiple CPUs.

Very true.

I'm investigating a spinlock-style SignalSemaphore that has a lower latency for protecting frequently used internal data structures in Exec.

Just so people know - even though I am one of the m68k developers for AROS, AROS SillySMP is *not* targeted for m68k. It is only for *existing* processors with *actual* SMP hardware.

Once someone puts an actual piece of SMP m68k hardware into my hands, I'll be happy to develop for it.