SMP Kernel

SMP Kernel

[Matias]

Hello,
When an SMP enabled kernel is booted on a Dual Core x86 machine ( Core 
0-1 ) I guess the Kernel is decompressed and started on core 0.
At some point in time the kernel becomes SMP aware and can then 
distribute threads on Cores 0 and 1.

Now, does the non-threaded part of the kernel with the scheduler 
continue to run solely on Core 0?

Cheers // Matias

Re: SMP Kernel

[zaharov]

Matias wrote:
> Hello,
> When an SMP enabled kernel is booted on a Dual Core x86 machine ( Core
> 0-1 ) I guess the Kernel is decompressed and started on core 0.
> At some point in time the kernel becomes SMP aware and can then
> distribute threads on Cores 0 and 1.
>
> Now, does the non-threaded part of the kernel with the scheduler
> continue to run solely on Core 0?
>
> Cheers // Matias
> -- 
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
Kernel may run on any core .
When kernel end bootstrap and run init he execute hlt op.
After all live in kernel  interrupt driven.

Re: SMP Kernel

[Matias]

Hi,
Ok, since the memory is shared between all the cores the Kernel can be 
invoked by any core receiving an interrupt and thus executed by that core?

If the above is right then how come that two separate CPUs can wake up, 
schedule and context-switch completely in parallel?
Are there an independent scheduler per cpu?

Directly from the sched-design.txt

- 'perfect' SMP scalability. With the new scheduler there is no 'big'
   runqueue_lock anymore - it's all per-CPU runqueues and locks - two
   tasks on two separate CPUs can wake up, schedule and context-switch
   completely in parallel, without any interlocking. All
   scheduling-relevant data is structured for maximum scalability.


Thx // Matias





zaharov skrev:
> Matias wrote:
>   
>> Hello,
>> When an SMP enabled kernel is booted on a Dual Core x86 machine ( Core
>> 0-1 ) I guess the Kernel is decompressed and started on core 0.
>> At some point in time the kernel becomes SMP aware and can then
>> distribute threads on Cores 0 and 1.
>>
>> Now, does the non-threaded part of the kernel with the scheduler
>> continue to run solely on Core 0?
>>
>> Cheers // Matias
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>>     
> Kernel may run on any core .
> When kernel end bootstrap and run init he execute hlt op.
> After all live in kernel  interrupt driven.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>   

Re: SMP Kernel

[zaharov]

Matias wrote:
> Hi,
> Ok, since the memory is shared between all the cores the Kernel can be
> invoked by any core receiving an interrupt and thus executed by that
> core?
>
> If the above is right then how come that two separate CPUs can wake
> up, schedule and context-switch completely in parallel?
> Are there an independent scheduler per cpu?
>
> Directly from the sched-design.txt
>
> - 'perfect' SMP scalability. With the new scheduler there is no 'big'
>   runqueue_lock anymore - it's all per-CPU runqueues and locks - two
>   tasks on two separate CPUs can wake up, schedule and context-switch
>   completely in parallel, without any interlocking. All
>   scheduling-relevant data is structured for maximum scalability.
>
>
> Thx // Matias
>
>
>
>
>
> zaharov skrev:
>> Matias wrote:
>>  
>>> Hello,
>>> When an SMP enabled kernel is booted on a Dual Core x86 machine ( Core
>>> 0-1 ) I guess the Kernel is decompressed and started on core 0.
>>> At some point in time the kernel becomes SMP aware and can then
>>> distribute threads on Cores 0 and 1.
>>>
>>> Now, does the non-threaded part of the kernel with the scheduler
>>> continue to run solely on Core 0?
>>>
>>> Cheers // Matias
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
>>>     
>> Kernel may run on any core .
>> When kernel end bootstrap and run init he execute hlt op.
>> After all live in kernel  interrupt driven.
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>   
> -- 
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Kernel use IPC primitives. All shared resources like lists, buffers,etc
protect by spinlock,mutex,etc.
Scheduler not run completely in parallel.
Scheduler  run like this [lock_shred_resource -> shcedule ->
unlock_shared_resource]
I think this list not for discuss this. You need read any Operating
system design book.
IMHO
 

RE: SMP Kernel

[David Schwartz]

> Hi,
> Ok, since the memory is shared between all the cores the Kernel can be
> invoked by any core receiving an interrupt and thus executed by that core?

Right.

> If the above is right then how come that two separate CPUs can wake up,
> schedule and context-switch completely in parallel?
> Are there an independent scheduler per cpu?

There is a scheduler that can run on any CPU that needs to schedule.
However, the scheduler is designed to be scalable across large numbers of
CPUs.

There is meaningful distinction between "there is one scheduler that can run
on any CPU" and "each CPU has its own scheduler". Whether you look at the
scheduler running on one CPU as the same scheduler or a different scheduler
as the scheduler running on another CPU is purely a question of semantics.

If I run two copies of 'ls', are they the same program or not?

> Directly from the sched-design.txt
>
> - 'perfect' SMP scalability. With the new scheduler there is no 'big'
>    runqueue_lock anymore - it's all per-CPU runqueues and locks - two
>    tasks on two separate CPUs can wake up, schedule and context-switch
>    completely in parallel, without any interlocking. All
>    scheduling-relevant data is structured for maximum scalability.

So the scheduler operates on per-CPU data structures, allowing multiple CPUs
to run the scheduler code at the same time without slowing each other down.

DS