Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1353300 > unrolled thread

[PATCH -tip 0/3] locking/rtmutex: Another crack at spin on owner

Back to article view | Back to linux.kernel

Contents

  [PATCH -tip 0/3] locking/rtmutex: Another crack at spin on owner Davidlohr Bueso <dave@stgolabs.net> - 2016-03-08 19:30 +0100
    [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Davidlohr Bueso <dave@stgolabs.net> - 2016-03-08 23:10 +0100
      Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Peter Zijlstra <peterz@infradead.org> - 2016-03-14 14:50 +0100

#1353300 — [PATCH -tip 0/3] locking/rtmutex: Another crack at spin on owner

Hi,

This is a (painfully late) followup to proposal sometime ago to add
spin on owner to rtmutexes. My first attempt was rather liberal in that
I tried avoiding the pi-dance and let the lock be stolen. However, due to
-rt constraints this series only deals with top-waiter, based on what we
do in the preempt rt patchset.

First two patches are trivial and the whole patchset as survived a week
of locktorture+pi_stress pounding at the same time without anything
breaking. That said, I'm sure it needs more testing and eyeballs, these
paths make my head hurt.

Thanks!

Davidlohr Bueso (3):
  rtmutex: Delete save_state member of struct rt_mutex
  rtmutex: Add rt_mutex_init_waiter helper
  rtmutex: Reduce top-waiter blocking on a lock

 include/linux/rtmutex.h         |  1 -
 kernel/Kconfig.locks            |  4 ++
 kernel/futex.c                  |  5 +--
 kernel/locking/rtmutex.c        | 82 +++++++++++++++++++++++++++++++++++------
 kernel/locking/rtmutex_common.h | 17 ++++++++-
 5 files changed, 92 insertions(+), 17 deletions(-)

-- 
2.1.4

[toc] | [next] | [standalone]

#1353437 — [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock

The very nature of rt_mutex_handle_deadlock() implies that this
patch is merely a formality, as in practice the saved barrier
is of little use. That said, we can relax setting the task state
and be done with it; blocking unconditionally... this is a deadlock!

Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---
  kernel/locking/rtmutex.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 8eb99b7f1ac8..c3d3c8e8ea5c 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1216,7 +1216,7 @@ static void rt_mutex_handle_deadlock(int res, int detect_deadlock,
  	 */
  	rt_mutex_print_deadlock(w);
  	while (1) {
-		set_current_state(TASK_INTERRUPTIBLE);
+		__set_current_state(TASK_INTERRUPTIBLE);
  		schedule();
  	}
  }
-- 
2.1.4

[toc] | [prev] | [next] | [standalone]

#1357243 — Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock

On Tue, Mar 08, 2016 at 02:05:39PM -0800, Davidlohr Bueso wrote:
> The very nature of rt_mutex_handle_deadlock() implies that this
> patch is merely a formality, as in practice the saved barrier
> is of little use. That said, we can relax setting the task state
> and be done with it; blocking unconditionally... this is a deadlock!
> 
> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
> ---
>  kernel/locking/rtmutex.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index 8eb99b7f1ac8..c3d3c8e8ea5c 100644
> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -1216,7 +1216,7 @@ static void rt_mutex_handle_deadlock(int res, int detect_deadlock,
>  	 */
>  	rt_mutex_print_deadlock(w);
>  	while (1) {
> -		set_current_state(TASK_INTERRUPTIBLE);
> +		__set_current_state(TASK_INTERRUPTIBLE);
>  		schedule();

So you're right that it doesn't matter here, however for that very
reason I would suggest not using __set_current_state() before schedule()
unless there is a _really_ good reason, and then with an extensive
comment to go with.

Otherwise people will manage to pick this as an example to copy and who
all knows what kind of borkage will result from that.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web