Home > Archive > Unix Programming > May 2004 > Is the unix kernel multithreaded?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Is the unix kernel multithreaded?
|
|
|
| Is the unix kernel multithreaded? (*unix* could refer to Linux,
Solaris etc.)
I've heard (in lots of places) of the BeOS kernel being heavily
multithreaded.
Does the same hold for unix kernels too?
What exactly would it mean for a kernel to be multithreaded? Would
that mean that individual kernel calls would create threads within
themselves to increase performance?
Now again, wouldn't that actually impede performance at the kernel
level for a single processor machine?
| |
| Måns Rullgård 2004-05-12, 9:08 pm |
| debajit1@hotmail.com (Slash) writes:
> Is the unix kernel multithreaded? (*unix* could refer to Linux,
> Solaris etc.)
>
> I've heard (in lots of places) of the BeOS kernel being heavily
> multithreaded.
> Does the same hold for unix kernels too?
>
> What exactly would it mean for a kernel to be multithreaded?
This has to be answered before anything can be said about the
multithreadedness of any specific kernel.
> Would that mean that individual kernel calls would create threads
> within themselves to increase performance?
>
> Now again, wouldn't that actually impede performance at the kernel
> level for a single processor machine?
--
Måns Rullgård
mru@kth.se
| |
| Søren Hansen 2004-05-12, 9:08 pm |
| On Wed, 12 May 2004 00:16:27 -0700, Slash wrote:
> Is the unix kernel multithreaded? (*unix* could refer to Linux,
> Solaris etc.)
The Linux kernel has threading capabilites within the kernel itself.
E.g. kswapd runs in a separate thread in the kernel.
> I've heard (in lots of places) of the BeOS kernel being heavily
> multithreaded.
> Does the same hold for unix kernels too?
That depends on how you'd define "heavily multithreaded".
> What exactly would it mean for a kernel to be multithreaded?
The way I see it, it means that the kernel has the ability to create a
separate thread that runs in kernel space, which handles a particular
part of the kernel's duties.
> Now again, wouldn't that actually impede performance at the kernel level
> for a single processor machine?
I could, but in most cases, it doesn't. Using kernel threads delegates the
scheduling responsibility to the kernel's scheduler. If this is not done,
you have to rely on each part of the kernel to give up its control of the
processor in order for other parts of the system to get some work done.
This COULD be done, but in many respects it places the responsibility of
the continued function of the kernel in the particular parts of the
kernel without the possibility for the scheduler to regain control.
--
Salu2, Søren.
| |
| Jem Berkes 2004-05-12, 9:08 pm |
| > What exactly would it mean for a kernel to be multithreaded? Would
> that mean that individual kernel calls would create threads within
> themselves to increase performance?
I don't exactly know what you mean by multithreaded kernel. Processes and
threads are facilities provided by the kernel itself; remember that on a
single processor, code can't execute simultaneously but rather the kernel
intervenes on (IO, timeout, syscall, etc.) and starts executing new code.
But there are high priority threads running on UNIX systems that are part
of the kernel itself. These threads are still subject to the kernel's
scheduling, of course, it's just that they get higher priorities when
pitted against any user level process.
--
Jem Berkes
http://www.sysdesign.ca/
| |
| Eric Sosman 2004-05-12, 9:08 pm |
| Jem Berkes wrote:
>
>
> I don't exactly know what you mean by multithreaded kernel. Processes and
> threads are facilities provided by the kernel itself; remember that on a
> single processor, code can't execute simultaneously but rather the kernel
> intervenes on (IO, timeout, syscall, etc.) and starts executing new code.
>
> But there are high priority threads running on UNIX systems that are part
> of the kernel itself. These threads are still subject to the kernel's
> scheduling, of course, it's just that they get higher priorities when
> pitted against any user level process.
On Solaris, user-level threads in the Real-Time scheduling
class have higher priority than kernel-level threads in the
System class, which in turn have higher priority than "ordinary"
user threads in the Interactive and Time-Sharing classes. There
are finer priority gradations within each of these classes, too:
nothing is so complex it can't be further complexified!
Oh, yes: The Solaris kernel is multi-threaded, emphatically so.
--
Eric.Sosman@sun.com
|
|
|
|
|