[PLUG] Multithreading

Kyle Hayes kyle at silverbeach.net
Sat Nov 22 10:18:02 UTC 2003


On Saturday 22 November 2003 00:19, Chris Jantzen wrote:
> On Fri, Nov 21, 2003 at 11:35:17PM -0800, Kevin Theobald wrote:
> > Chris Jantzen writes:
> >  > Multiprogramming with processes is simpler, safer, and much more
> >  > standardized.
> >
> > And a lot slower.
>
> No. Not a lot. As I mentioned, in Linux the only difference between
> process forks and kernel threads is the way clone() was called. Linux is
> very proud of its scheduler and syscall interface reducing the overhead
> of process switching to unheard of speed.

Depends a bit on the type of hardware.  With a process, you've usually got to 
do a fair amount of memory remapping.  That can be expensive.  TLB flushing 
can result on some processors and that can really be expensive (the refill).  
Processors with process tags on the TLB entries often lessen this impact.

> I was pointing Michael towards process multiprogramming as a way to learn
> things more safely, anyways.
>
> > you happen to have more threads/processors than physical CPUs, because
> > switching threads is MUCH faster than switching processes.  (Switching
>
> Just to reiterate, this is not true in Linux. And in 2.6 (or 2.4 with
> O(1) patches) it just gets better and better.

The scheduler knows what process to run next in O(1) time, but the amount of 
work to do the switch depends on the type of process (full process, thread, 
something in between), and I think on what kinds of things the process did.  
I believe that if the process does not use floating point, the switch is 
somewhat faster as the scheduler doesn't push the floating point context.  I 
may be wrong on this.  There are a lot of variables and it is hard to make 
too many generic statements.

All that said, Linux is definitely one of the best platforms on which to do 
multiprocess code.  Compared to most platforms, it is very fast and effecient 
at process switching.  With threads, it is even faster (or will be in 2.6).

Best,
Kyle





More information about the PLUG mailing list