Linux-kernel mailing list archive 1999-37,: Re: linux threads vs. solaris threads

# Re: linux threads vs. solaris threads

David Lang (dlang@diginsite.com)
Mon, 13 Sep 1999 13:16:30 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Nicolas Lescastreyres: "suscribe"
- Previous message: Wade Hampton: "Re: Lockups - lost interrupt"

As I have not seen anyone else respond to this I will give it a stab.

short answer

Solaris has a two step scheduler where scheduling a process takes 10-100
times as long as to schedule a thread

Linux process scheduling is on the same order of magnatude as the solaris
thread scheduler (I don't remember which is faster, but they are very
close).

As a result of this Linus and others decided not to add a second level
scheduler to linux on the basis that most scheduling will be between
processes anyway and to add a second layer would slow down the "normal"
case.

Instead what is available is a variation of fork called "clone" which
creates another process that shares the memory region of the parent
instead of having it's own memory area. This allows a thread library to
simulate almost every funcion of POSTIX threads (the only parts that are
sot currently simulated are the symantic of all threads having the same
PID, and sending one thread a halt signal haling all threads, the second
at least is being worked on.)

I am an observer to this, not a kernal hacker so please correct me if I am
misunderstanding any of this.

David Lang

On Sat, 11 Sep 1999, Hrafnkell Eiriksson wrote:

> Date: Sat, 11 Sep 1999 11:04:43 +0000
> From: Hrafnkell Eiriksson <he@kvintus.dk>
> To: linux-kernel@vger.rutgers.edu
> Subject: linux threads vs. solaris threads
>
>
> Hi
>
> Few days ago in my concurrent programming class the teacher stated
> that the time it takes the OS to switch between threads (i.e. threads
> created with pthreads_create()/clone(CLONE_VM|CLONE_FILES etc)) was
> probably higher in Linux than in Solaris (and other commercial Unices)
> on the same hardware.
> He based his assumption on the fact that a Linux thread is actually
> a process (seen with the eyes of the kernel) and the Linux kernel
> doesn't have the concept of a thread as Solaris. Therefore Linux has
> to switch contexts when switching between threads but Solaris doesn't
> have to do a context switch as the threads were running in the same
> context (and no we were not confusing Linux threads and Solaris
> userspace threads, we were talking about kernel level threads in
> both systems).
> He added that he didn't have any data or couldn't reference
> any source to back up his claim so he might be wrong.
>
> I found his statement interesting as I recalled seeing somewhere that
> switching between processes (and threads) in Linux took less time than
> switching between processes in Solaris. I decided to try to figure
> out if his statement was true.
>
> I found the lmbench benchmark that tries to measure the time it takes
> to do a context switch. Checking the lmbench source shows that it
> creates new processes with fork() and measures the time it takes
> to do a context switch between them. I don't think that this measurement
> is a fair measurement for the time it takes to switch between threads
> as there is no need to flush the TLB wich has to be done when doing a
> switch between processes if I have understood the purpose of a TLB
> correctly (but I might be wrong as I dont understand this well enough).
> So I concluded that lmbench was not the right tool to measure this and
> answer my question.
>
> As far as I understand, switching between threads in Linux means
> changing the PC counter, the stackpointer and restoring the registers
> and FP state. Solaris probably does something similar.
>
> Can anyone here help me determine if my teacher is right or wrong on
> this (or isn't there a right/wrong answer? :) or point me
> to webpages, articles, books or benchmarking tools?
> Also, is there any more "context switch" involved in switching
> between threads in Linux than in Solaris? A Linux thread
> created with the clone() system call has the same virtual
> memory and same file descriptors as other threads running
> with it within the same process so there isn't really any
> context to switch between except changing the state of
> the CPU.
>
> Thanks in advance for your time and your help.
>
> Hrafnkell
> --
> //-----------------------//-------------------------------------------------
> // Hrafnkell Eiriksson //
> // he@kvintus.dk //
> // TF3HR // "Blessed are they who go around in circles,
> // // for they shall be known as Wheels"
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> 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.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Nicolas Lescastreyres: "suscribe"
- Previous message: Wade Hampton: "Re: Lockups - lost interrupt"