From: Mike Galbraith <efault@gmx.de>
To: Thomas Pilarski <thomas.pi@arcor.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Andrew Morton <akpm@linux-foundation.org>,
Gregory Haskins <ghaskins@novell.com>,
bugme-daemon@bugzilla.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Bugme-new] [Bug 12562] New: High overhead while switching or synchronizing threads on different cores
Date: Fri, 30 Jan 2009 08:57:50 +0100 [thread overview]
Message-ID: <1233302270.6061.9.camel@marge.simson.net> (raw)
In-Reply-To: <1233237934.11129.183.camel@bugs-laptop>
On Thu, 2009-01-29 at 15:05 +0100, Thomas Pilarski wrote:
> > In short this program is carefully crafted to defeat all our affinity
> > tests - and I'm not sure what to do.
>
> I am sorry, although it is not carefully crafted. The function random()
> is causing my problem. I currently have no real data, so I tried to make
> some random utilization and data.
Yeah, rather big difference, mega-contention vs zero-contention.
2.6.28.2, profile of ThreadSchedulingIssue 4 524288 8 200
vma samples % app name symbol name
ffffffff80251efa 2574819 31.6774 vmlinux futex_wake
ffffffff80251a39 1367613 16.8255 vmlinux futex_wait
0000000000411790 815426 10.0320 ThreadSchedulingIssue random
ffffffff8022b3b5 343692 4.2284 vmlinux task_rq_lock
0000000000404e30 299316 3.6824 ThreadSchedulingIssue __lll_lock_wait_private
ffffffff8030d430 262906 3.2345 vmlinux copy_user_generic_string
ffffffff80462af2 235176 2.8933 vmlinux schedule
0000000000411b90 210984 2.5957 ThreadSchedulingIssue random_r
ffffffff80251730 129376 1.5917 vmlinux hash_futex
ffffffff8020be10 123548 1.5200 vmlinux system_call
ffffffff8020a679 119398 1.4689 vmlinux __switch_to
ffffffff8022f49b 110068 1.3541 vmlinux try_to_wake_up
ffffffff8024c4d1 106352 1.3084 vmlinux sched_clock_cpu
ffffffff8020be20 102709 1.2636 vmlinux system_call_after_swapgs
ffffffff80229a2d 100614 1.2378 vmlinux update_curr
ffffffff80248309 86475 1.0639 vmlinux add_wait_queue
ffffffff80253149 85969 1.0577 vmlinux do_futex
Versus using myrand() free sample cruft generator from rand(3) manpage. Poof.
vma samples % app name symbol name
004002f4 979506 90.7113 ThreadSchedulingIssue myrand
00400b00 53348 4.9405 ThreadSchedulingIssue thread_consumer
00400c25 42710 3.9553 ThreadSchedulingIssue thread_producer
One of those "don't _ever_ do that" things?
-Mike
next prev parent reply other threads:[~2009-01-30 7:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-12562-10286@http.bugzilla.kernel.org/>
2009-01-28 20:56 ` [Bugme-new] [Bug 12562] New: High overhead while switching or synchronizing threads on different cores Andrew Morton
2009-01-28 22:15 ` Peter Zijlstra
2009-01-28 22:25 ` Thomas Pilarski
2009-01-29 9:07 ` Peter Zijlstra
2009-01-29 10:12 ` Thomas Pilarski
2009-01-29 10:24 ` Thomas Pilarski
2009-01-29 10:31 ` Peter Zijlstra
2009-01-29 11:37 ` Peter Zijlstra
2009-01-29 14:05 ` Thomas Pilarski
2009-01-30 7:57 ` Mike Galbraith [this message]
2009-02-02 7:43 ` Thomas Pilarski
2009-02-02 8:19 ` Peter Zijlstra
2009-02-02 8:33 ` Thomas Pilarski
2009-02-02 8:52 ` Mike Galbraith
2009-02-02 8:55 ` Peter Zijlstra
2009-02-02 12:15 ` Peter Zijlstra
2009-02-02 18:29 ` Michael Kerrisk
2009-02-02 18:35 ` Peter Zijlstra
2009-02-03 4:55 ` Mike Galbraith
2009-02-03 3:56 ` Valdis.Kletnieks
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=1233302270.6061.9.camel@marge.simson.net \
--to=efault@gmx.de \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=ghaskins@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas.pi@arcor.de \
/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.