From: Darren Hart <dvhltc@us.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Michel Lespinasse <walken@google.com>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] futex: add FUTEX_SET_WAIT operation
Date: Mon, 30 Nov 2009 14:09:52 -0800 [thread overview]
Message-ID: <4B1442B0.6000402@us.ibm.com> (raw)
In-Reply-To: <1258447807.7816.20.camel@laptop>
Peter Zijlstra wrote:
Hey Peter,
Some thoughts on adaptive futexes ...
> Subject: futex: implement adaptive spin
> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Tue Jan 20 14:40:36 CET 2009
>
> Implement kernel side adaptive spining for futexes.
>
> This is implemented as a new futex op: FUTEX_WAIT_ADAPTIVE, because it
> requires the futex lock field to contain a TID and regular futexes do
> not have that restriction.
>
> FUTEX_WAIT_ADAPTIVE will spin while the lock owner is running (on a
> different cpu) or until the task gets preempted. After that it behaves
> like FUTEX_WAIT.
>
> The spin loop tries to acquire the lock by cmpxchg(lock, 0, tid) == tid
> on the lower 30 bits (TID_MASK) of the lock field -- leaving the
> WAITERS and OWNER_DIED flags in tact.
>
> NOTE: we could fold mutex_spin_on_owner() and futex_spin_on_owner() by
> adding a lock_owner function argument.
>
> void lock_spin_on_owner(struct thread_info *(*lock_owner)(void *lock),
> void *lock, struct thread_info *owner);
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> ...
> Index: linux-2.6/kernel/futex.c
> ===================================================================
> --- linux-2.6.orig/kernel/futex.c
> +++ linux-2.6/kernel/futex.c
> @@ -1158,10 +1158,40 @@ handle_fault:
> */
> #define FLAGS_SHARED 0x01
> #define FLAGS_CLOCKRT 0x02
> +#define FLAGS_ADAPTIVE 0x03
>
> static long futex_wait_restart(struct restart_block *restart);
>
> -static int futex_wait(u32 __user *uaddr, int fshared,
> +#ifdef CONFIG_SMP
> +struct thread_info *futex_owner(u32 __user *uaddr)
> +{
> + struct thread_info *ti = NULL;
> + struct task_struct *p;
> + pid_t pid;
> + u32 uval;
> +
> + if (get_futex_value_locked(&uval, uaddr))
> + return NULL;
Just give up if it would cause a fault?
> +
> + pid = uval & FUTEX_TID_MASK;
> + rcu_read_lock();
> + p = find_taks_by_vpid(pid);
I'm impressed that you can create such a solid patch without compiling it!
> + if (p) {
> + const struct cred *cred, *pcred;
> +
> + cread = current_cred();
> + pcred = __task_cred(p);
> + if (cred->euid == pcred->euid ||
> + cred->euid == pcred->uid)
> + ti = task_thread_info(p);
> + }
> + rcu_read_unlock();
> +
> + return ti;
> +}
> +#endif
> +
> +static int futex_wait(u32 __user *uaddr, int flags,
> u32 val, ktime_t *abs_time, u32 bitset, int clockrt)
> {
> struct task_struct *curr = current;
> @@ -1176,11 +1206,43 @@ static int futex_wait(u32 __user *uaddr,
> if (!bitset)
> return -EINVAL;
>
> +#ifdef CONFIG_SMP
> + if (!futex_cmpxchg_enabled || !(flags & FLAGS_ADAPTIVE))
> + goto skip_adaptive;
> +
> + preempt_disable();
> + for (;;) {
> + struct thread_info *owner;
> + u32 curval = 0, newval = task_pid_vnr(curr);
Do we need to lookup newval every iteration?
> +
> + owner = futex_owner(uaddr);
> + if (owner && futex_spin_on_owner(uaddr, owner))
> + break;
> +
> + if (get_futex_value_locked(&uval, uaddr))
> + break;
> +
> + curval |= uval & ~FUTEX_TID_MASK;
> + newval |= uval & ~FUTEX_TID_MASK;
> +
> + if (cmpxchg_futex_value_locked(uaddr, curval, newval)
> + == newval)
"== curval" isn't it? futex_atomic_cmpxchg_inatomic() returns the
oldval, not the newval.
> + return 0;
> +
> + if (!owner && (need_resched() || rt_task(curr)))
> + break;
Hrm... why go through the loop at all for an rt_task if we bail on the
first iteration?
> +
> + cpu_relax();
> + }
> + preempt_enable();
> +skip_adaptive:
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
next prev parent reply other threads:[~2009-11-30 22:09 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
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 [this message]
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=4B1442B0.6000402@us.ibm.com \
--to=dvhltc@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox