Re: [PATCH 2/3] locking: ww_mutex: Allow to use rt_mutex instead of mutex for the baselock
From: Peter Zijlstra
Date: Tue Mar 10 2015 - 08:31:10 EST
On Fri, Feb 27, 2015 at 05:57:08PM +0100, Sebastian Andrzej Siewior wrote:
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index 16b2d3cc88b0..0a652ba46081 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -106,6 +106,7 @@ void __sched mutex_lock(struct mutex *lock)
> EXPORT_SYMBOL(mutex_lock);
> #endif
>
> +#ifndef CONFIG_WW_MUTEX_RTMUTEX
> static __always_inline void ww_mutex_lock_acquired(struct ww_mutex *ww,
> struct ww_acquire_ctx *ww_ctx)
> {
> @@ -215,6 +216,7 @@ ww_mutex_set_context_slowpath(struct ww_mutex *lock,
> wake_up_process(cur->task);
> }
> }
> +#endif
Should we shuffle the code a bit to collect all the ww_mutex functions
in one #ifdef block?
> #ifdef CONFIG_MUTEX_SPIN_ON_OWNER
> /*
> @@ -328,6 +330,7 @@ static bool mutex_optimistic_spin(struct mutex *lock,
> while (true) {
> struct task_struct *owner;
>
> +#ifndef CONFIG_WW_MUTEX_RTMUTEX
> if (use_ww_ctx && ww_ctx->acquired > 0) {
> struct ww_mutex *ww;
>
> @@ -343,7 +346,7 @@ static bool mutex_optimistic_spin(struct mutex *lock,
> if (READ_ONCE(ww->ctx))
> break;
> }
> -
> +#endif
> /*
> * If there's an owner, wait for it to either
> * release the lock or go to sleep.
> @@ -356,12 +359,14 @@ static bool mutex_optimistic_spin(struct mutex *lock,
> if (mutex_try_to_acquire(lock)) {
> lock_acquired(&lock->dep_map, ip);
>
> +#ifndef CONFIG_WW_MUTEX_RTMUTEX
> if (use_ww_ctx) {
> struct ww_mutex *ww;
> ww = container_of(lock, struct ww_mutex, base);
>
> ww_mutex_set_context_fastpath(ww, ww_ctx);
> }
> +#endif
>
> mutex_set_owner(lock);
> osq_unlock(&lock->osq);
> @@ -445,6 +450,7 @@ void __sched mutex_unlock(struct mutex *lock)
>
> EXPORT_SYMBOL(mutex_unlock);
Are those ifdefs really needed, if we provide stubs and ensure to only
call mutex_optimistic_spin/__mutex_lock_common with .ww_ctx=NULL,
.use_ww_ctx = false, this should all just go away without #ifdefs,
right?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/