linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <ognen@gene.pbi.nrc.ca>
To: <linux-kernel@vger.kernel.org>
Subject: Re: threading question (results after thread pooling)
Date: Thu, 14 Jun 2001 16:42:29 -0600 (CST)	[thread overview]
Message-ID: <Pine.LNX.4.30.0106141632200.3287-100000@gene.pbi.nrc.ca> (raw)
In-Reply-To: <E15Abem-00055Y-00@the-village.bc.nu>

Hello,

I have implemented thread pooling (with an environment variable
where I can give the number of threads to be created). Results:

1. Linux, no change in the times (not under 2.2.x or 2.4)

2. SGI/Solaris/OSF/1: times decrease when the number of threads matched
the number of processors available. The times were the same as my
previous version or couple of percents better when I exhaggerated the
number of threads to create, say, 128 threads on a 2 CPU.

3. The load on the machines has decreased considerably with the new
solution. I consider this to be the only positive impact I have seen from
this solution.

The solution is basically designed in the following way:

1. Threads are created and they wait on a condition with pthread_cond_wait
2. The main thread sets up the data (which are global) and then signals
that there is work to be done on the same condition variable. The first
thread to get awaken takes the work. the remaining threads keep waiting.
3. Go to 2. until there is work to distribute

I am now pretty much inclined to believe that it is either a) hardware
issue (someone mentioned that SPARCs and MIPSes handle things differently)
or b) Linux for some reason just cant give me what IRIX/Solaris can in
this particular case

Regretfully, the organization I work for prohibits me from releasing the
code I am talking about until the lawyers decide what to do with it. My
hope is to be able to release it for free to anyone interested since this
sequence alignment tool is used a lot :). This kind of defeats the purpose
of my question(s) since without the code it is difficult to talk.

Best regards,
Ognen Duzlevski

On Thu, 14 Jun 2001, Alan Cox wrote:

> > they are done. This should help it (and avoid the pthread_create,
> > pthread_exit). I will implement this and report my results if there is
> > interest.
>
> You should also check up the cache colouring. X86 boxes have relatively poor
> memory performance and most x86 chips have lousy behaviour when data bounces
> between processors or is driven out of cache

-- 
Ognen Duzlevski
Plant Biotechnology Institute
National Research Council of Canada
Bioinformatics team



  reply	other threads:[~2001-06-14 22:44 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-12 18:24 threading question ognen
2001-06-12 18:39 ` Davide Libenzi
2001-06-12 18:57 ` from dmesg: kernel BUG at inode.c:486 Olivier Sessink
2001-06-12 18:58 ` threading question Christoph Hellwig
2001-06-12 19:07   ` ognen
2001-06-12 19:15     ` Kip Macy
2001-06-12 19:29       ` Christoph Hellwig
2001-06-12 19:15     ` Christoph Hellwig
2001-06-13 12:20     ` Kurt Garloff
2001-06-13 13:35       ` J . A . Magallon
2001-06-13 14:17         ` Philips
2001-06-13 15:06           ` ognen
2001-06-12 21:44   ` Davide Libenzi
2001-06-12 21:48     ` ognen
2001-06-14 18:15       ` Alan Cox
2001-06-14 22:42         ` ognen [this message]
2001-06-14 23:00           ` threading question (results after thread pooling) Mike Castle
2001-06-12 21:58     ` threading question Albert D. Cahalan
2001-06-12 23:48       ` J . A . Magallon
2001-06-12 19:06 ` Kip Macy
2001-06-12 19:14   ` Alexander Viro
2001-06-12 19:25     ` Russell Leighton
2001-06-12 23:27       ` Mike Castle
2001-06-13 17:31   ` bert hubert
2001-06-14  6:45     ` Helge Hafting
2001-06-14 18:28   ` Alan Cox
2001-06-14 19:01     ` bert hubert
2001-06-14 19:22       ` Russell Leighton
2001-06-15 11:29       ` Anil Kumar
2001-06-14 23:05     ` J . A . Magallon
2001-06-16 14:16     ` Michael Rothwell
2001-06-16 15:19       ` Alan Cox
2001-06-16 18:33         ` Russell Leighton
2001-06-16 19:06         ` Michael Rothwell
2001-06-16 21:30           ` Coroutines [was Re: threading question] Russell Leighton
2001-06-12 22:41 ` threading question Pavel Machek
2001-06-14 23:20 threading question (results after thread pooling) Dieter Nützel

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=Pine.LNX.4.30.0106141632200.3287-100000@gene.pbi.nrc.ca \
    --to=ognen@gene.pbi.nrc.ca \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: threading question (results after thread pooling)' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).