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
next prev parent 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.