AROS SMP Research: Technical Discussion

[itix]

If it spends 1% of time in forbid then you will lose 1% of each cpu core, 20% of it's time in forbid and you will lose 20% of each cpu.

I think problem is not how much time is spent in Forbid() but overhead required to synchronize CPUs. In single core systems Forbid() is extremely light weight call. The same goes with Disable() which was implemented as simple assembler macro on old 68k days.

Now problem is that many many Exec calls are heavily depending on Disable()/Enable() to protect internal data structures. The message passing system in Exec is extremely light weight and used a lot in the system and in applications but in multicore systems it is far from ideal.

Having to stop other CPUs only to AddTail() new message is massive overhead.

[itix]

If it spends 1% of time in forbid then you will lose 1% of each cpu core, 20% of it's time in forbid and you will lose 20% of each cpu.

Oh, btw... you have to consider that other CPUs can call forbid not just that first one. When adding more CPUs chances to be in forbid state increases.

Problem could be demonstrated using silly pingpong task sending message back and worth constantly. Because sending a message requires forbid that task that could easily render other cores useless. Even when running at low priority it would disrupt higher priority task on other cores, due to forbid/disable semantics.

The net effect is high priority tasks run slower on multicore system than they would run on single core system.

[itix]

Tell me how you will find out what the percentage of time various software will spend in forbid without trying it?

Getting accurate results can be difficult but itcould be profiled. At least how many calls to Forbid() or Disable() there are per minute...

You have always been able to write software for AmigaOS which disturbs high priority tasks. If it turns out that this is a problem that needs solving then you could try changing it so that cpu's will only ever be running a task that has the same priority. As high priority tasks are supposed to run for a short period of time then wasting the other cores during that time may not be a big deal. If you have a high priority task on AmigaOS that takes a long time then it becomes unusable (standard priority tasks like workbench won't be allowed to run at all). The priority in AmigaOS is quite fine grained (-128 to 127 IIRC) which means you could also derail this using as many as possible. But there is no reason why software that can take advantage of SMP shouldn't have limitations (like all Tasks that run at the same time have to run at the same priority).

I know what you mean. There is a hope that at least sometimes some software could run on parallel. Even if you get only +10% instead of +100% it is better than nothing. In the future bottlenecks could be removed one by one.

I understand about the Forbid() overhead, if something spins in a Forbid()/Permit() call then it could cause problems. But is that something that any software should need/want to do? We pretty much have the source to all AROS software at this point & this isn't going to affect AROS 68k.

Often Forbid() or Disable() is called indirectly. Take this example:

Code: [Select]

sillypseudocode()
{
   SetTaskPri(SysBase->ThisTask, -128);
   PutMsg(port, msg);

   while (true)
      PutMsg(GetMsg(port));
}

PutMsg() and GetMsg() have hidden Disable() but that is fine because on single core system high priority tasks get scheduled as soon as Enable() is called.

On multicore this would steal almost all available CPU time from each core.

Having Disable() free messaging system would solve this problem but this would have implications to all software. Another solution could be limiting scheduler to not schedule lower priority tasks on other cores as you mentioned.

Anyway, I just wanted to point out that biggest culprit is the OS itself and write some silly example

[itix]

I can play too.
 

Code: [Select]


sillypseudocode()
{
   Forbid();
   while (true);
}

 
Sure there are pathological cases, The easiest way to speed up your program is for the user to not run it.

You missed one very important difference. My example would run just fine on any traditional non-SMP Amiga OS system. Your example wouldnt.

Change Forbid() to SetTaskPri(task, 127) and you would have an example where SMP is superior to non-SMP system.

[itix]

AROS is in the process of breaking all binary compatibility with past AROS versions anyway, so it's perfect timing for the SMP work as all apps will need to be recompiled, but frankly I just don't believe that it's worth being all that concerned about breaking compatibility over this - the systems where we may want to care about compatibility are the classics, and it's not like they are SMP systems anyway...

This is not just a user application problem. Also the OS internals depend on Forbid/Enable and replacing Forbid/Enable in one OS call can cause serious implications to other parts in the OS.