Page 1 of 2
multi-core /parallel programming
Posted: Sat Jan 05, 2008 2:55 pm
by jcmatias
In parallel programming there are paralelism at task level and intruction level
In multi-core precessor the intructions level parallelism is provide by hardware (pipeline, out of order execution, branch prediction etc). Tasks level parallelism can achived by threads, but can i select a preocessor to execute a instrucion or task?
How can I select a specific processor to execute a task or thread ?
How can I select a specific processor to execute a instruction ?
In other words, there are instrucions to select a preocessor to execute a task or instruction ?
Posted: Sat Jan 05, 2008 6:08 pm
by bewing
Each core has an entire register set, including ESP and EIP. Each core is running complete programs, independently. You set up the registers of the other cores, start them at a particular instruction in their EIP -- and they go off running programs all by themselves. You do not micromanage them at the level you are describing. The cores "communicate" with each other through their APICs and through the computer's main memory that they all share.
Posted: Wed Jan 09, 2008 5:22 pm
by Jef
bewing wrote:Each core has an entire register set, including ESP and EIP. Each core is running complete programs, independently. You set up the registers of the other cores, start them at a particular instruction in their EIP -- and they go off running programs all by themselves. You do not micromanage them at the level you are describing. The cores "communicate" with each other through their APICs and through the computer's main memory that they all share.
Yes, but how you select the target cpu ?
At the scheduler you save old registers (current task) and then you load the new task registers. But when you say eax, ebx, etc the target cpu is the first.
Is there any instructions or cpu registers that inform cpu which is the target core?
Posted: Wed Jan 09, 2008 6:35 pm
by Laksen
As your computer boots the BSP(boot service processor) has control. Your kernel should get loaded like it's a UP(uniprocessor system). Then you search the SMP or ACPI table for processor entries. If you find more than one then your PC should have multiple cores. Then you choose to boot the AP's. You do this by sending interrupts to the designated AP's local APIC. In this interrupt you tell the AP where it should start. Then you would have two kernel's running so to say. They can essentially be running the same code, and you can access the same memory and by that way talk between the processors.
Posted: Wed Jan 09, 2008 7:29 pm
by Jef
Laksen wrote:As your computer boots the BSP(boot service processor) has control. Your kernel should get loaded like it's a UP(uniprocessor system). Then you search the SMP or ACPI table for processor entries. If you find more than one then your PC should have multiple cores. Then you choose to boot the AP's. You do this by sending interrupts to the designated AP's local APIC. In this interrupt you tell the AP where it should start. Then you would have two kernel's running so to say. They can essentially be running the same code, and you can access the same memory and by that way talk between the processors.
i see. thanx
Posted: Wed Jan 23, 2008 6:59 pm
by Jef
Laksen wrote:As your computer boots the BSP(boot service processor) has control. Your kernel should get loaded like it's a UP(uniprocessor system). Then you search the SMP or ACPI table for processor entries. If you find more than one then your PC should have multiple cores. Then you choose to boot the AP's. You do this by sending interrupts to the designated AP's local APIC. In this interrupt you tell the AP where it should start. Then you would have two kernel's running so to say. They can essentially be running the same code, and you can access the same memory and by that way talk between the processors.
As far as i understand, a cpu with two/four cores uses the same memory,
so the kernel's scheduler runs twice (one per core) and uses the same process array. A process is marked as busy, so the other core scheduler bypass this process (prevention of loading the same process in two cores).
Depend on scheduler design,
Is it possible the same process loaded in core1, and at another time loaded in core2 without problems?
But if you have 2 real cpu, every cpu has its own physical memory.
I don't know if paging is a way to "merge" the memory of two cpus,
if not, i suppose that its impossible to load the same process to different cpu (in different time). Also, must be a way to communicate the two (real) cpu with a shared memory (i am sure it exist).
The other issue is the IRQs. Is there a 2nd PIC for the 2nd cpu?
For one cpu with two/four cores, when an IRQ fires up, execution is stopped only in core that creates the IRQ?
Posted: Wed Jan 23, 2008 8:14 pm
by Laksen
Jef wrote:
But if you have 2 real cpu, every cpu has its own physical memory.
I don't know if paging is a way to "merge" the memory of two cpus,
if not, i suppose that its impossible to load the same process to different cpu (in different time). Also, must be a way to communicate the two (real) cpu with a shared memory (i am sure it exist).
The other issue is the IRQs. Is there a 2nd PIC for the 2nd cpu?
For one cpu with two/four cores, when an IRQ fires up, execution is stopped only in core that creates the IRQ?
Wrong. The CPU's act like they were a single CPU in the computer. If you have 2 CPU's(in a x86 environment) the only thing they don't have in common generally speaking is the internal registers(eax, edi, eip, etc), the interrupt descriptor table, the control registers, the global descriptor table and the local apic. All memory is shared equally. CPU1 and CPU2 can access the same memory completely without each other knowing it.
There's only one PIC in a computer. But the interrupts will be directed to each CPU and core from this PIC. As your CPU's will have their own IDT you can do virtually what you want with the interrupts on CPU basis
Posted: Wed Jan 23, 2008 9:43 pm
by Jef
i see.
I was confused because in a motherboard with two cpus you need a at least one memory chip per cpu.
Posted: Thu Jan 24, 2008 2:41 am
by JamesM
Jef wrote:i see.
I was confused because in a motherboard with two cpus you need a at least one memory chip per cpu.
No you don't. I have a dual celeron 400MHz testbed with one RAM chip in.
Most (if not all) x86 systems are SMP - "Symmetric". That is, all processors access the same RAM. NUMA is "non uniform memory access", and that is the opposite.
Posted: Thu Jan 24, 2008 4:47 am
by Aku-Aku
Could somebody be so kind to give me a link about SMP for beginners?
I didn't find anything like this in Wiki.
Posted: Thu Jan 24, 2008 5:29 am
by AJ
Posted: Thu Jan 24, 2008 6:39 am
by Aku-Aku
Thanks a lot AJ.
Posted: Thu Jan 24, 2008 9:00 am
by bewing
Jef wrote:
... so the kernel's scheduler runs twice (one per core) and uses the same process array.
I just wanted to make sure you had this one point straight. You are right that there is generally one scheduler per core. But they almost always use
different memory allocations (within the one big compter memory area that they share),
different process tables, and are running a completely different set of programs and drivers -- and often don't even know what processes and drivers the other schedulers are running.
Posted: Thu Jan 24, 2008 7:00 pm
by Jef
I have a process array that i keep all registers (while task switch) and some other info. I mark with a flag the process that is running.
I suppose that the other scheduler (on the 2nd core) will read the same process array and bypass the running process.
I don't have complete the multi-core detection (btw the tutorial you say above is nice).
Just tell me if the my theory is correct or not, to know how i must continue.
Posted: Fri Jan 25, 2008 5:45 am
by jal
Laksen wrote:There's only one PIC in a computer. But the interrupts will be directed to each CPU and core from this PIC. As your CPU's will have their own IDT you can do virtually what you want with the interrupts on CPU basis
That seems hugely inefficient, each CPU/core getting interrupted with each interrupt, while probably only one of them will handle a given interrupt.
JAL