From: Con Kolivas <kernel@kolivas.org>
To: Marcel Zalmanovici <MARCEL@il.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Inconsistent timing results of multithreaded program on an SMP machine.
Date: Sun, 20 Nov 2005 20:54:50 +1100 [thread overview]
Message-ID: <200511202054.50690.kernel@kolivas.org> (raw)
In-Reply-To: <OFEF2B25AC.706FA8BA-ONC22570BF.00336502-C22570BF.0033F2B7@il.ibm.com>
On Sun, 20 Nov 2005 20:27, Marcel Zalmanovici wrote:
> Hi,
>
> I am trying, as part of my thesis, to make some improvement to the linux
> scheduler.
> Therefore I've written a small multithreaded application and tested how
> long on average it takes for it to complete.
>
> The results were very surprising. I expected to see the completion time
> vary 1 to 2 seconds at most.
> Instead what I've got was an oscillation where the maximum time was twice
> and more than the minimum!! For a short test results ranged ~7sec to ~16
> sec, and the same happened to longer tests where the min was ~1min and the
> max ~2:30min.
>
> Does anyone have any clue as to what might happen ?
> Is there anything I can do to get stable results ?
>
> Here is a small test case program:
>
> (See attached file: sched_test.c)
>
> The test was always done on a pretty much empty machine. I've tried both
> kernel 2.6.4-52 and 2.6.13.4 but the results were the same.
>
> I'm working on a Xeon Intel machine, dual processor, hyperthreaded.
^^^^^^^^^^^^^^
I suspect what you're seeing is the random nature of threads to bind either to
a hyperthread sibling or a real core. If all your threads land on only one
physical cpu and both hyperthread siblings it will run much slower than if
half land on one physical cpu and half on the other physical cpu. To confirm
this, try setting cpu affinity just for one logical core of each phyiscal cpu
(like affinity for cpu 1 and 3 only for example) or disabling hyperthread in
the bios.
Cheers,
Con
next prev parent reply other threads:[~2005-11-20 9:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-20 9:27 Inconsistent timing results of multithreaded program on an SMP machine Marcel Zalmanovici
2005-11-20 9:54 ` Con Kolivas [this message]
2005-11-20 10:18 ` Marcel Zalmanovici
2005-11-20 10:28 ` Con Kolivas
2005-11-20 10:35 ` Muli Ben-Yehuda
2005-11-20 10:39 ` Con Kolivas
2005-11-20 10:43 ` Muli Ben-Yehuda
2005-11-20 10:50 ` Marcel Zalmanovici
2005-11-20 10:50 ` Con Kolivas
2005-11-20 10:43 ` Marcel Zalmanovici
2005-11-20 14:02 ` Paul Jackson
2005-11-24 9:50 ` Marcel Zalmanovici
[not found] <OF507D27BA.6B51F19A-ONC22570C3.002E62D2-C22570C3.002F0C99@il.ibm.com>
2005-11-24 9:40 ` Con Kolivas
2005-11-24 10:00 ` Marcel Zalmanovici
2005-11-24 12:43 ` Paul Jackson
2005-12-04 15:26 ` Marcel Zalmanovici
2005-12-04 19:54 ` Paul Jackson
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=200511202054.50690.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=MARCEL@il.ibm.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.