public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gregory Maxwell <greg@linuxpower.cx>
To: Michael Rothwell <rothwell@holly-springs.nc.us>
Cc: linux-kernel@vger.kernel.org
Subject: Re: high load & poor interactivity on fast thread creation
Date: Wed, 27 Dec 2000 12:25:09 -0500	[thread overview]
Message-ID: <20001227122508.A29579@xi.linuxpower.cx> (raw)
In-Reply-To: <3A266895.F522A0E2@austin.ibm.com> <20001130081443.A8118@bach.iverlek.kotnet.org> <3A266895.F522A0E2@austin.ibm.com> <4.3.2.7.2.20001227110018.00e5ba90@cam-pop.cambridge.arm.com> <3A4A22A8.D434B7F@holly-springs.nc.us>
In-Reply-To: <3A4A22A8.D434B7F@holly-springs.nc.us>; from rothwell@holly-springs.nc.us on Wed, Dec 27, 2000 at 12:11:04PM -0500

On Wed, Dec 27, 2000 at 12:11:04PM -0500, Michael Rothwell wrote:
[snip]
> One notable difference between Linux and NT threads and processes is
> that it is more expensive to create new processes on NT than on Linux,
> and on NT thread creation is cheaper than process creation. Typically
> Windows programs use multiple threads rather than multiple processes,
> whereas on Unix the reverse is true.

This is the meaty difference. Under Linux, full *process* operations 
are faster then NT *thread* operations. The Linux 'threads' (lightweight
processes) are somewhat faster then unlightweight processes, but nowhere
near the magnitude of difference that NT experiences.

Because of this, lightweight processes are used differently under Linux: They
are treated just like processes and can share variable amounts of state with
other processes.

In Linux, you use threads when it makes sense to code with threads. You can
share as little or as much makes sense with your design. You almost never use
threads for performance reasons, because regular processes are so fast that
it seldom makes sense to use threads for performance (they can be faster but
usually the additional development/debugging difficulty makes it a non-issue).

In Windows NT, you MUST use threads for decent performance in many places
where processes (or other different semi-lightweight structures) might make
more sense. Threads are the largest construction capable of really good
performance, so you don't have the flexibility to chose what you share:
What is shared is not a programming design decision but an OS performance
decision.
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2000-12-27 17:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-30  7:14 high load & poor interactivity on fast thread creation Arnaud Installe
2000-11-30 14:47 ` Ray Bryant
2000-11-30 16:11   ` Arnaud Installe
2000-11-30 16:37     ` James A Sutherland
2000-12-27 11:01   ` Ruth Ivimey-Cook
2000-12-27 17:11     ` Michael Rothwell
2000-12-27 17:25       ` Gregory Maxwell [this message]
2000-12-27 17:32         ` Larry McVoy
2000-12-27 19:43           ` Andrea Arcangeli
2000-11-30 16:12 ` Alan Cox
2000-11-30 23:00 ` David Lang
2000-12-01  9:47   ` Arnaud Installe
2000-12-01 21:20     ` David Lang

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=20001227122508.A29579@xi.linuxpower.cx \
    --to=greg@linuxpower.cx \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rothwell@holly-springs.nc.us \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox