All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaud Installe <ainstalle@filepool.com>
To: Ray Bryant <raybry@austin.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: high load & poor interactivity on fast thread creation
Date: Thu, 30 Nov 2000 17:11:37 +0100	[thread overview]
Message-ID: <20001130171137.A1851@bartok.filepool.com> (raw)
In-Reply-To: <20001130081443.A8118@bach.iverlek.kotnet.org> <3A266895.F522A0E2@austin.ibm.com>
In-Reply-To: <3A266895.F522A0E2@austin.ibm.com>; from raybry@austin.ibm.com on Thu, Nov 30, 2000 at 08:47:49AM -0600

On Thu, Nov 30, 2000 at 08:47:49AM -0600, Ray Bryant wrote:
> The IBM implementations of the Java language use native threads --
> the result is that every time you do a Java thread creation, you
> end up with a new cloned process.  Now this should be pretty fast,

Well, I think the problem is that it is *too* fast.  :-/  What I think
happens is that a lot of threads get created at the same time, and they
all run a bit of initialization code.  This way a lot of processes are in
the running state, so that the load average gets *very* high, which makes
the system very unresponsive.

Could this be correct ?  Also, I haven't seen this happen with NT.  Could
it be that Java on NT uses user-mode threading and creates threads much
more slowly, resulting in a lower load ?

> so I am surprised that it stalls like that.  It is possible this
> is a scheduler effect.  Do you have a program example you can
> share with us?

So I suppose it is a scheduler effect.  Can this be solved on the kernel
side (a /proc/sys setting perhaps ?), or should a check be built-in into
the software that no more than a certain number of threads are created per
time unit ?

> Also, it is a little old now (by Internet standards) but you 
> might take a look at this paper we did at the beginning of 
> the year: 
>  
> http://www-4.ibm.com/software/developer/library/java2/index.html

I've already read this one.  I'll have to re-read it to freshen up my
memory.

							Arnaud

-- 
Arnaud Installe						<ainstalle@filepool.com>

Absence is to love what wind is to fire.  It extinguishes the small,
it enkindles the great.
-
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-11-30 16: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 [this message]
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
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=20001130171137.A1851@bartok.filepool.com \
    --to=ainstalle@filepool.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raybry@austin.ibm.com \
    /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.