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: Mon, 23 Nov 2009 09:21:19 -0800 [thread overview]
Message-ID: <4B0AC48F.7020501@us.ibm.com> (raw)
In-Reply-To: <20091121023636.GA13763@google.com>
Michel Lespinasse wrote:
> On Thu, Nov 19, 2009 at 03:13:40PM -0800, Darren Hart wrote:
>>> 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).
>
> As we found out in private email conversation before, this was due to hitting
> resource allocation limits while creating the threads. The patch below
> (relative to your set_wait branch) should fix this.
>
> Patch summary:
> * Added FUTEX_WAIT_BITSET/FUTEX_WAKE_BITSET definitions - I do have
> old enough headers that this was a problem now that you use
> inline functions in futextest.h
Great, thanks.
> * Changed futex_cmpxchg return type to int - I dont really like this change,
> but otherwise gcc complains about the volatile keyword being ignored in
> the returned function type. Feel free to ignore this if you like.
Hrm. Which version of gcc? I've tested with 4.1 and 4.4 with the -Wall
option, neither complain for me.
> * futex_setwait_lock: changed to a more compact & faster implementation
> (same algorithm but wrote the loop in a different way)
> * test harness: look at pthread_create return code; if thread creation fails
> then join with existing threads and exit. Also moved the before/after
> barrier logic into the test harness rather than the futex_[set]wait_test
> functions.
I'll split these up and apply - with the exception of the futex_cmpxchg
bit until we sort out what's going on. It would facilitate patch
integration in the future if you could break things up functionally and
use use "git format-patch" to generate the patches.
Again, thank you for the contributions.
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
next prev parent reply other threads:[~2009-11-23 17:21 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
2009-11-21 2:36 ` Michel Lespinasse
2009-11-23 17:21 ` Darren Hart [this message]
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=4B0AC48F.7020501@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.