Messages in this thread | | | Date | Wed, 07 Apr 2010 10:31:32 -0700 | From | Darren Hart <> | Subject | Re: [PATCH 5/6] futex: handle timeout inside adaptive lock spin |
| |
Thomas Gleixner wrote: > On Mon, 5 Apr 2010, Darren Hart wrote: > >> Signed-off-by: Darren Hart <dvhltc@us.ibm.com> >> --- >> kernel/futex.c | 24 +++++++++++++++++++++--- >> 1 files changed, 21 insertions(+), 3 deletions(-) >> >> diff --git a/kernel/futex.c b/kernel/futex.c >> index c33ac2a..af61dcd 100644 >> --- a/kernel/futex.c >> +++ b/kernel/futex.c >> @@ -2385,6 +2385,7 @@ out: >> /** >> * trylock_futex_adaptive() - Try to acquire the futex lock in a busy loop >> * @uaddr: the futex user address >> + * @timeout: absolute timeout or NULL if none >> * >> * Try to acquire a futex lock in a loop until the owner changes or the owner >> * is descheduled. To lock the futex, set the value to the current TID. >> @@ -2394,10 +2395,11 @@ out: >> * 1 - Futex lock acquired >> * <0 - On error >> */ >> -static int trylock_futex_adaptive(u32 __user *uaddr) >> +static int trylock_futex_adaptive(u32 __user *uaddr, ktime_t *timeout) >> { >> int ret = 0; >> u32 curval; >> + ktime_t now; >> >> for (;;) { >> struct thread_info *owner; >> @@ -2433,6 +2435,22 @@ static int trylock_futex_adaptive(u32 __user *uaddr) >> if (need_resched()) >> break; >> >> + if (timeout) { >> + now = ktime_get(); > > Hmm. Calling that in every iteration might hurt especially on non > TSC systems, but well...
I haven't come across a better alternative since arming the timer before setting TASK_INTERRUPTIBLE isn't appropriate.
> >> +/* FIXME: consider creating ktime_less_than(lhs, rhs) */ > > No need. The .tv64 comparison works in both cases. :)
Ah, for some reason I was thinking that was only the case if CONFIG_KTIME_SCALAR was set. Very nice, thanks.
-- Darren Hart IBM Linux Technology Center Real-Time Linux Team
| |