From: "J . A . Magallon" <jamagallon@able.es>
To: Fabio Riccardi <fabio@chromium.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: linux scheduler limitations?
Date: Fri, 30 Mar 2001 00:33:56 +0200 [thread overview]
Message-ID: <20010330003356.C1052@werewolf.able.es> (raw)
In-Reply-To: <3AC3A6C9.991472C0@chromium.com> <20010329233521.C6053@werewolf.able.es> <3AC3B35D.FC010700@chromium.com>
In-Reply-To: <3AC3B35D.FC010700@chromium.com>; from fabio@chromium.com on Fri, Mar 30, 2001 at 00:12:45 +0200
On 03.30 Fabio Riccardi wrote:
>
> Despite of all apparences this method performs beautifully on Linux, pthreads
> are
> actually slower in many cases, since you will incur some additional overhead
> due
> to thread synchronization and scheduling.
>
It all depends on your app, as every parallel algorithm. In a web-ftp-whatever
server, you do not need any synchro. You can start threads in free run and
let them die alone.
> The problem is that beyond a certain number of processes the scheduler just
> goes
> bananas, or so it seems to me.
>
> Since Linux threads are mapped on processes, I don't think that (p)threads
> woud
> help in any way, unless it is the VM context switch overhead that is playing a
> role here, which I wouldn't think is the case.
>
You said, 'mapped'.
AFAIK, that is the advantage, you can avoid the VM switch by sharing memory.
--
J.A. Magallon # Let the source
mailto:jamagallon@able.es # be with you, Luke...
Linux werewolf 2.4.2-ac28 #1 SMP Thu Mar 29 16:41:17 CEST 2001 i686
next prev parent reply other threads:[~2001-03-29 22:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-29 21:19 linux scheduler limitations? Fabio Riccardi
2001-03-29 21:26 ` David Lang
2001-03-29 21:55 ` Fabio Riccardi
2001-03-30 1:45 ` Mike Kravetz
2001-03-30 2:58 ` Fabio Riccardi
2001-03-29 21:35 ` J . A . Magallon
2001-03-29 22:12 ` Fabio Riccardi
2001-03-29 22:33 ` J . A . Magallon [this message]
2001-03-29 22:51 ` Fabio Riccardi
2001-03-30 6:52 ` Giuliano Pochini
2001-04-02 22:58 ` Alan Cox
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=20010330003356.C1052@werewolf.able.es \
--to=jamagallon@able.es \
--cc=fabio@chromium.com \
--cc=linux-kernel@vger.kernel.org \
/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.