Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
Who's Online
23 user(s) are online (20 user(s) are browsing Forum)

Members: 0
Guests: 23

more...

Browsing this Thread:   1 Anonymous Users



(1) 2 3 »


How much work in Aros supporting Multi Core Processors

Joined:
2008/6/7 13:52
Group:
Member
Posts: 2051
Offline
With the obvious gradual demise of single core x86 processors and the belief I have picked up that Aros does not support multicore cpu's, is it a huge undertaking to support these in the near future. Otherwise we will be limiting the speed of future systems. CPU speeds are not really increasing and all effort is in more cores, dual, quad, etc.

Forgive me for saying this and I hope some one will correct my ignorance, but the Amiga was designed with a multi task based OS and it is a "simple" jump to spread them on other processors. I know it is not simple but is it doable.

Steve

Posted on: 2009/1/4 10:53
Transfer the post to other applications Transfer


Re: How much work in Aros supporting Multi Core Processors

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 884
Offline
Hello

I have also wandered/dreamed of an multicore Aros, so much so that i digget around for information on SMP support.

First of all to even get the other cores (Application processors or AP's) to boot Aros would need some APIC support (yes there's one on 64bit side, but i run Aros 32bit on 64bit machine...) APIC wakes AP(s) when bootstrap processor (BSP) instructs it so.

Then there's that IRQ issues... Don't know if this is any problem... (should BSP only handle IRQ's?)

Exec's task list would need to be protected as more than one CPU could access it, don't know if it all ready is (i think not) and then there would need to be n-number of running task pointers corresponding to number of cores running those tasks.

Our tasks could not care less which core they run on.

Inter processor communication? As Aros has no memory map (MMU) "features" i would like to think that this would not be any problem (normal exec messaging, but what about them IRQ's then...) Are those IPC's even needed? Task ends -> CPU registers goes to mem, other core continues -> CPU registers come from mem...

If someone would write that APIC.hidd on 32bit side then all that is needed is few lines to get those APs running on something (busy loop for starters)

I don't know if CPU needs to be on 64bit space to get SMP working... i hope not! I dont need that much memory space, those 64bit wide writes to mem are nice thou (or are they wider, like 128bits when on supporting hardware?)

Posted on: 2009/1/5 7:00
Transfer the post to other applications Transfer


Re: How much work in Aros supporting Multi Core Processors

Joined:
2004/3/29 9:54
From Scotland "The Cold"
Group:
Member
Posts: 1769
Offline
Making AROS run code on a 2nd/3rd etc AP/core should be relatively simple - on AROS-x86_64 it already sets up extra cores and puts them effectively into an idle state. It still needs support code to push a thread onto a core currently before it can be used properly in such a fashion.

Making scheduling support multi AP's will need a bit more work.. and having full SMP would require a lot of atomic fixes to code, aswell as possibly abstracting the notion of a thread of execution away from the task context a little.

Im not sure what would be the best way of dealing with IRQ handling but i would suspect it would be more efficient to offload handling to the least active AP.

Posted on: 2009/1/5 8:14
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: How much work in Aros supporting Multi Core Processors

Joined:
2008/6/7 13:52
Group:
Member
Posts: 2051
Offline
Unfortunately I am a dumb programmer, always dreamed of one day being able to create device drivers in my sleep. Then woke up and realised in the words of Dirty Harry. "A man has to know his limitations".

So I leave this idea to other geniuses to decide if doable. I do believe that whilst Aros was started before Dual Core came around, the future is multi core because speeds cannot climb at the old rate. So we will hit a roof, now to be honest that is a way off with desktop systems and my system shows just how good it can run in 3.1ghz. My concern is that low price internet devices will run at say dual 1.6ghz ish like the Intel ITX boards and that is when we want the extra core.

Still an idea for when Aros reaches v1.o status and v2 is planned.

Thanks for your replies.

Steve

Posted on: 2009/1/5 11:30
Transfer the post to other applications Transfer


Re: How much work in Aros supporting Multi Core Processors

Joined:
2004/10/30 17:13
From Ireland
Group:
Member
Posts: 2137
Offline
@Kalamatee:

Could the x86_64 APIC code be ported to 32-bit AROS, or would it have to be done largely from scratch?

Posted on: 2009/1/5 15:33
Transfer the post to other applications Transfer


Re: How much work in Aros supporting Multi Core Processors

Joined:
2004/3/29 9:54
From Scotland "The Cold"
Group:
Member
Posts: 1769
Offline
It should run almost as is - only the boot code for the APs might need a little modification.

AFAIK michal was going to backport the x86_64 kernel to i386 so you might want to ask him.

Posted on: 2009/1/5 17:11
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: How much work in Aros supporting Multi Core Processors

Joined:
2004/3/30 23:19
From Clausthal-Zellerfeld, Germany
Group:
Member
Posts: 388
Offline
Quote:

ncafferkey wrote:

Could the x86_64 APIC code be ported to 32-bit AROS, or would it have to be done largely from scratch?


Yes, it can. The most significant difference would be the boot code for APs. This piece of code would become a tiny bit shorter and simplier.

Posted on: 2009/1/5 23:20
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: How much work in Aros supporting Multi Core Processors

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 884
Offline
Id really like to get some of those nice new things from 64bit side done on 32bit too... Well michalsc, please, please pretty please...

I have a guts feeling that Aros would not need that much of a work to get SMP going, as it has been the same thing with the OS since the 80's... Tasks running time has never been known for sure, so everything that needs to be protected HAS to be protected, even on single core prosessors, programmed as if multiple tasks would be running at the same time. (now they really don't, they run in sequence) in a sense AmigaOS has been multicore ready since it was born (correct me if i'm wrong)

When i think of SMP support i don't think it so that multiple cores would run the same task at the same time, Nooooooo! If only one task would exists, it would be run on only one core at a time! No Linux s*it about threads for now...

Execbase needs modification to allow SMP, for now it is assumed to be ran on single processor, but as more than one task/core could be now running on it those list/pointers need protection.
One could also make a n-number of lists of those tasks related things.

Posted on: 2009/1/6 0:39
Transfer the post to other applications Transfer


Re: How much work in Aros supporting Multi Core Processors

Joined:
2004/3/30 23:19
From Clausthal-Zellerfeld, Germany
Group:
Member
Posts: 388
Offline
Quote:

I have a guts feeling that Aros would not need that much of a work to get SMP going, as it has been the same thing with the OS since the 80's... Tasks running time has never been known for sure, so everything that needs to be protected HAS to be protected, even on single core prosessors, programmed as if multiple tasks would be running at the same time. (now they really don't, they run in sequence) in a sense AmigaOS has been multicore ready since it was born (correct me if i'm wrong)


You're neither completely right nor completely wrong :)

AROS would need a lot of work to get SMP done right.

1. First of all, each CPU core needs to have it's own local copy of SysBase. Otherwise, fields like eg. ThisTask would loose their validity.

2. Each CPU core would need to have the SysBase at the same global location. Having pointer to SysBase would not be enough because a program might cache the value and reuse it later. IT means that each CPU would have to use it's own MMU memory map.

3. AROS would need to have a core manager which would be responsible for migration of tasks between cores. You may be right by telling that the migration of a task across CPUs is time expensive, but without such governor there would be a risk, that eg. three cores are idling and one is busy with few tasks.

4. The last but not least - many system structures are protected by Disable()/Enable() pair which is killing the performance on SMP systems. Some system elements are protected by Forbid()/Permit() calls. Both pairs should not only stop the multitasking and reception of interrupts on all cores, but also block currently running tasks. In Disable() and Forbid() states only one task is permitted to run.


Yes, SMP is nice, but adding it to AROS is a huge task. Doing it right is even harder :)

Posted on: 2009/1/6 2:32
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: How much work in Aros supporting Multi Core Processors

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 884
Offline
Quote:

michalsc wrote:

1. First of all, each CPU core needs to have it's own local copy of SysBase. Otherwise, fields like eg. ThisTask would loose their validity.

2. Each CPU core would need to have the SysBase at the same global location. Having pointer to SysBase would not be enough because a program might cache the value and reuse it later. IT means that each CPU would have to use it's own MMU memory map.

3. AROS would need to have a core manager which would be responsible for migration of tasks between cores. You may be right by telling that the migration of a task across CPUs is time expensive, but without such governor there would be a risk, that eg. three cores are idling and one is busy with few tasks.

4. The last but not least - many system structures are protected by Disable()/Enable() pair which is killing the performance on SMP systems. Some system elements are protected by Forbid()/Permit() calls. Both pairs should not only stop the multitasking and reception of interrupts on all cores, but also block currently running tasks. In Disable() and Forbid() states only one task is permitted to run.


1. In my mind i don't think there would be need for any copy of execbase. Every core accesses the same execbase, it only needs to be modified... When task switch occurs, the core doing the switch would semaphore the list of tasks ready for running/waiting then it would get its ID (0 for BSP, 1 for AP1 etc... or get it before semaphore) then it would access *ThisTask[ID] and put it to sleep and get next ready task and set it up and release semaphore.

2. Above invalidates this need.

3. I have Ubuntu installed on this dual core machine and it really does bad job putting those threads running, e.g i've noticed on regular basis that core 1 would be 100% and core 2 some few %, and then it toggles... Why not let them task race for CPU time on Aros, they do that anyway?

4. We should not use Forbid/Permit to protect any structures, let alone use Disable/Enable (they are meant for disabling multitasking and they do exactly that) One should use semaphores IF disabling multitasking/interrupts is not really wanted. The use of Disable has ALLWAYS been discouraged, since the 80's...

Forbid() might be expanded to Forbid(THIS_CORE) if task wants some more time or to Forbid(GLOBAL) if it does not want any switches...

One more note, wasn't Disable() meant to only disable interrupts, but as a side effect it also blocks multitasking?

Posted on: 2009/1/6 3:15
Transfer the post to other applications Transfer



(1) 2 3 »



You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.

[Advanced Search]


Search
Top Posters
1 paolone
paolone
3765
2 nikolaos
nikolaos
3470
3 magorium
magorium
3125
4 phoenixkonsole
phoenixkonsole
3072
5 deadwood
deadwood
2371
6 ncafferkey
ncafferkey
2137
7 mazze
mazze
2070
8 clusteruk
clusteruk
2051
9 damocles
damocles
1771
10 Kalamatee
Kalamatee
1769
© 2004-2014 AROS Exec