public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Artem S. Tashkinov" <t.artem@lycos.com>
To: linux-kernel@vger.kernel.org
Subject: HT (Hyper Threading) aware process scheduling doesn't work as it should
Date: Sun, 30 Oct 2011 19:57:12 +0000 (GMT)	[thread overview]
Message-ID: <269467866.49093.1320004632156.JavaMail.mail@webmail17> (raw)

Hello,

It's known that if you want to reach maximum performance on HT enabled Intel CPUs you
should distribute the load evenly between physical cores, and when you have loaded all
of them you should then load the remaining virtual cores.

For example, if you have 4 physical cores and 8 virtual CPUs then if you have just four
tasks consuming 100% of CPU time you should load four CPU pairs:

VCPUs: {1,2} - one task running

VCPUs: {3,4} - one task running

VCPUs: {5,6} - one task running

VCPUs: {7,8} - one task running

It's absolutely detrimental to performance to bind two tasks to e.g. two physical cores
{1,2} {3,4} and then the remaining two tasks to e.g. the third core 5,6:

VCPUs: {1,2} - one task running

VCPUs: {3,4} - one task running

VCPUs: {5,6} - *two* task runnings

VCPUs: {7,8} - no tasks running

I've found out that even on Linux 3.0.8 the process scheduler doesn't correctly distributes
the load amongst virtual CPUs. E.g. on a 4-core system (8 total virtual CPUs) the process
scheduler often run some instances of four different tasks on the same physical CPU.

Maybe I shouldn't trust top/htop output on this matter but the same test carried out on
Microsoft XP OS shows that it indeed distributes the load correctly, running tasks on different
physical cores whenever possible.

Any thoughts? comments? I think this is quite a serious problem.

Best wishes,

Artem

             reply	other threads:[~2011-10-30 20:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-30 19:57 Artem S. Tashkinov [this message]
2011-10-30 21:26 ` HT (Hyper Threading) aware process scheduling doesn't work as it should Henrique de Moraes Holschuh
2011-10-30 21:51   ` Artem S. Tashkinov
2011-10-31  9:16     ` Henrique de Moraes Holschuh
2011-10-31  9:40       ` Artem S. Tashkinov
2011-10-31 11:58         ` Henrique de Moraes Holschuh
2011-11-01  4:14           ` Zhu Yanhai
2011-11-01  5:15         ` ffab ffa
2011-10-31 18:59   ` Chris Friesen
2011-11-01  6:01     ` Mike Galbraith
2011-10-30 22:12 ` Arjan van de Ven
2011-10-30 22:29   ` Artem S. Tashkinov
2011-10-31  3:19     ` Yong Zhang
2011-10-31  8:18       ` Artem S. Tashkinov
2011-10-31 10:06 ` Con Kolivas
2011-10-31 11:42   ` Mike Galbraith
2011-11-01  0:41     ` Con Kolivas
2011-11-01  0:58       ` Gene Heskett
2011-11-01  5:08       ` Mike Galbraith
2011-11-03  8:18 ` Ingo Molnar
2011-11-03  9:44   ` Artem S. Tashkinov
2011-11-03 10:29     ` Ingo Molnar
2011-11-03 12:42     ` Henrique de Moraes Holschuh
2011-11-03 13:06       ` Artem S. Tashkinov
2011-11-03 13:00   ` Mike Galbraith

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=269467866.49093.1320004632156.JavaMail.mail@webmail17 \
    --to=t.artem@lycos.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox