All of lore.kernel.org
 help / color / mirror / Atom feed
From: zaharov <zaharov@sbmag.ru>
To: linux-kernel@vger.kernel.org
Subject: Re: SMP Kernel
Date: Sat, 21 Feb 2009 02:07:03 +1100	[thread overview]
Message-ID: <499EC717.3000502@sbmag.ru> (raw)
In-Reply-To: <499EC317.6010506@sundmangroup.com>

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
 

  reply	other threads:[~2009-02-20 15:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-20 13:59 SMP Kernel Matias
2009-02-20 14:14 ` zaharov
2009-02-20 14:49   ` Matias
2009-02-20 15:07     ` zaharov [this message]
2009-02-20 23:52     ` David Schwartz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=499EC717.3000502@sbmag.ru \
    --to=zaharov@sbmag.ru \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.