From: Darren Hart <dvhltc@us.ibm.com>
To: Michel Lespinasse <walken@google.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] futex: add FUTEX_SET_WAIT operation
Date: Thu, 19 Nov 2009 15:13:40 -0800 [thread overview]
Message-ID: <4B05D124.6020808@us.ibm.com> (raw)
In-Reply-To: <8d20b11a0911191325u49624854u6132594f13b0718c@mail.gmail.com>
Michel Lespinasse wrote:
>
>
> On Thu, Nov 19, 2009 at 9:03 AM, Darren Hart <dvhltc@us.ibm.com
> <mailto:dvhltc@us.ibm.com>> wrote:
>
> Michel Lespinasse wrote:
>
> On Tue, Nov 17, 2009 at 08:16:06AM -0800, Darren Hart wrote:
>
> http://git.kernel.org/?p=linux/kernel/git/dvhart/futextest.git
>
> Michael, would you be willing to include a version of this
> test in the above test suite? If so, then in keeping with
> the rest of the test suite, I would recommend splitting into
> two tests, one of each opcode being tested, and add
> argument to define thread count. The run.sh script would
> then run each thread count as a separate test run.
>
>
> There you go. Hope this helps. Feel free to adapt as needed.
>
> Signed-off-by: Michel Lespinasse <walken@google.com
> <mailto:walken@google.com>>
>
>
> My core-duo laptop hung after 256 threads. I left it running all
> night and woke to it still sitting at:
>
> 256 threads: 11792 Kiter/s (14.18s user 0.28s system 8.48s wall 1.71
> cores)
>
> Have experienced a hang with this test on any platform? I'll take a
> closer look at the source today to see if there is anything in there
> that requires a certain number of CPUs to function properly.
>
>
> Which test were you running, futex_wait_test or futex_setwait_test ?
This is futex_wait_test
>
> This is not supposed to require any particular number of CPUs, so I am
> concerned about the hang.
>
> How reproducible is this for you ? Do you know if the original test code
> I sent hanged in the same way ?
I'm basically 2 for 2 on each version of the futex_wait_test. I haven't
seen it run to completion yet. This is on a stock Ubuntu kernel
(2.6.31-15-generic) on my core duo laptop (32 bit).
Futex locking constructs are tricky. I'll spend some time looking over
the barriers and locks used in the test. I tried to do some simple
instrumenting, but that masked the hang (not unexpectedly). I'll keep
looking.
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
next prev parent reply other threads:[~2009-11-19 23:13 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-17 7:46 [PATCH] futex: add FUTEX_SET_WAIT operation Michel Lespinasse
2009-11-17 8:18 ` Ingo Molnar
2009-11-17 8:55 ` Peter Zijlstra
2009-11-17 16:16 ` Darren Hart
2009-11-18 3:37 ` Michel Lespinasse
2009-11-18 5:29 ` Darren Hart
2009-11-24 14:39 ` [PATCH 0/3] perf bench: Add new benchmark for futex subsystem Hitoshi Mitake
2009-11-24 14:39 ` [PATCH 1/3] perf bench: Add wrappers for atomic operation of GCC Hitoshi Mitake
2009-11-24 16:20 ` Darren Hart
2009-11-26 5:44 ` Hitoshi Mitake
2009-11-24 14:39 ` [PATCH 2/3] perf bench: Add new files for futex performance test Hitoshi Mitake
2009-11-24 16:33 ` Darren Hart
2009-11-26 5:53 ` Hitoshi Mitake
2009-11-26 5:56 ` [PATCH] futextest: Make locktest() in harness.h more general Hitoshi Mitake
2009-11-24 14:39 ` [PATCH 3/3] perf bench: Fix misc files to build files related to futex Hitoshi Mitake
2009-11-18 22:13 ` [PATCH] futex: add FUTEX_SET_WAIT operation Michel Lespinasse
2009-11-19 6:51 ` Darren Hart
2009-11-19 17:03 ` Darren Hart
[not found] ` <8d20b11a0911191325u49624854u6132594f13b0718c@mail.gmail.com>
2009-11-19 23:13 ` Darren Hart [this message]
2009-11-21 2:36 ` Michel Lespinasse
2009-11-23 17:21 ` Darren Hart
2009-11-17 17:24 ` Ingo Molnar
2009-11-17 17:27 ` Darren Hart
2009-11-18 1:49 ` Hitoshi Mitake
2009-11-17 8:50 ` Peter Zijlstra
2009-11-17 15:24 ` Linus Torvalds
2009-11-18 4:21 ` Michel Lespinasse
2009-11-18 5:40 ` Darren Hart
2009-11-30 22:09 ` Darren Hart
2009-12-03 6:55 ` [PATCH] futex: add FUTEX_SET_WAIT operation (and ADAPTIVE) Darren Hart
2009-11-17 17:22 ` [PATCH] futex: add FUTEX_SET_WAIT operation Darren Hart
2009-11-18 3:29 ` Michel Lespinasse
2009-11-18 0:13 ` Darren Hart
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=4B05D124.6020808@us.ibm.com \
--to=dvhltc@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=walken@google.com \
/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.