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

Groups > linux.kernel > #1407452 > unrolled thread

[PATCH] mutex: Do not spin/queue before performing ww_mutex deadlock avoidance

Back to article view | Back to linux.kernel

Contents

  [PATCH] mutex: Do not spin/queue before performing ww_mutex deadlock avoidance Chris Wilson <chris@chris-wilson.co.uk> - 2016-05-26 10:40 +0200
    Re: [PATCH] mutex: Do not spin/queue before performing ww_mutex  deadlock avoidance Maarten Lankhorst <maarten.lankhorst@linux.intel.com> - 2016-05-26 12:40 +0200
      Re: [PATCH] mutex: Do not spin/queue before performing ww_mutex  deadlock avoidance Chris Wilson <chris@chris-wilson.co.uk> - 2016-05-26 12:50 +0200
        Re: [PATCH] mutex: Do not spin/queue before performing ww_mutex  deadlock avoidance Maarten Lankhorst <maarten.lankhorst@linux.intel.com> - 2016-05-26 13:10 +0200
    [PATCH] mutex: Report recursive ww_mutex locking early Chris Wilson <chris@chris-wilson.co.uk> - 2016-05-26 22:10 +0200
      Re: [PATCH] mutex: Report recursive ww_mutex locking early Maarten Lankhorst <maarten.lankhorst@linux.intel.com> - 2016-05-30 09:50 +0200
        Re: [PATCH] mutex: Report recursive ww_mutex locking early Peter Zijlstra <peterz@infradead.org> - 2016-05-30 11:20 +0200
          Re: [PATCH] mutex: Report recursive ww_mutex locking early Maarten Lankhorst <maarten.lankhorst@linux.intel.com> - 2016-05-30 11:50 +0200
            Re: [PATCH] mutex: Report recursive ww_mutex locking early Peter Zijlstra <peterz@infradead.org> - 2016-05-30 12:30 +0200
              Re: [PATCH] mutex: Report recursive ww_mutex locking early Chris Wilson <chris@chris-wilson.co.uk> - 2016-05-30 12:50 +0200
                Re: [PATCH] mutex: Report recursive ww_mutex locking early Maarten Lankhorst <maarten.lankhorst@linux.intel.com> - 2016-05-30 13:20 +0200

#1407452 — [PATCH] mutex: Do not spin/queue before performing ww_mutex deadlock avoidance

The ww_mutex has the property of allowing the lock to detect and report
when it may be used in deadlocking scenarios (to allow the caller to
unwind its locks and avoid the deadlock). This detection needs to be
performed before we queue up for the spin, otherwise we wait on the
osq_lock() for our turn to detect the deadlock that another thread is
spinning on, waiting for us. Otherwise as we are stuck behind our waiter,
throughput plummets.

This can be demonstrated by trying concurrent atomic modesets.

Testcase: igt/kms_cursor_legacy
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: linux-kernel@vger.kernel.org
---
 kernel/locking/mutex.c | 56 ++++++++++++++++++++++++++++++++------------------
 1 file changed, 36 insertions(+), 20 deletions(-)

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index e364b424b019..d60f1ba3e64f 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -217,12 +217,35 @@ ww_mutex_set_context_slowpath(struct ww_mutex *lock,
 }
 
 #ifdef CONFIG_MUTEX_SPIN_ON_OWNER
+static bool ww_mutex_may_deadlock(struct mutex *lock,
+				  struct ww_acquire_ctx *ww_ctx)
+{
+	if (ww_ctx && ww_ctx->acquired > 0) {
+		struct ww_mutex *ww;
+
+		ww = container_of(lock, struct ww_mutex, base);
+		/*
+		 * If ww->ctx is set the contents are undefined, only
+		 * by acquiring wait_lock there is a guarantee that
+		 * they are not invalid when reading.
+		 *
+		 * As such, when deadlock detection needs to be
+		 * performed the optimistic spinning cannot be done.
+		 */
+		if (READ_ONCE(ww->ctx))
+			return true;
+	}
+
+	return false;
+}
+
 /*
  * Look out! "owner" is an entirely speculative pointer
  * access and not reliable.
  */
 static noinline
-bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner)
+bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner,
+			 struct ww_acquire_ctx *ww_ctx)
 {
 	bool ret = true;
 
@@ -241,6 +264,11 @@ bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner)
 			break;
 		}
 
+		if (ww_mutex_may_deadlock(lock, ww_ctx)) {
+			ret = false;
+			break;
+		}
+
 		cpu_relax_lowlatency();
 	}
 	rcu_read_unlock();
@@ -251,7 +279,8 @@ bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner)
 /*
  * Initial check for entering the mutex spinning loop
  */
-static inline int mutex_can_spin_on_owner(struct mutex *lock)
+static inline int mutex_can_spin_on_owner(struct mutex *lock,
+					  struct ww_acquire_ctx *ww_ctx)
 {
 	struct task_struct *owner;
 	int retval = 1;
@@ -259,6 +288,9 @@ static inline int mutex_can_spin_on_owner(struct mutex *lock)
 	if (need_resched())
 		return 0;
 
+	if (ww_mutex_may_deadlock(lock, ww_ctx))
+		return 0;
+
 	rcu_read_lock();
 	owner = READ_ONCE(lock->owner);
 	if (owner)
@@ -308,7 +340,7 @@ static bool mutex_optimistic_spin(struct mutex *lock,
 {
 	struct task_struct *task = current;
 
-	if (!mutex_can_spin_on_owner(lock))
+	if (!mutex_can_spin_on_owner(lock, ww_ctx))
 		goto done;
 
 	/*
@@ -322,28 +354,12 @@ static bool mutex_optimistic_spin(struct mutex *lock,
 	while (true) {
 		struct task_struct *owner;
 
-		if (use_ww_ctx && ww_ctx->acquired > 0) {
-			struct ww_mutex *ww;
-
-			ww = container_of(lock, struct ww_mutex, base);
-			/*
-			 * If ww->ctx is set the contents are undefined, only
-			 * by acquiring wait_lock there is a guarantee that
-			 * they are not invalid when reading.
-			 *
-			 * As such, when deadlock detection needs to be
-			 * performed the optimistic spinning cannot be done.
-			 */
-			if (READ_ONCE(ww->ctx))
-				break;
-		}
-
 		/*
 		 * If there's an owner, wait for it to either
 		 * release the lock or go to sleep.
 		 */
 		owner = READ_ONCE(lock->owner);
-		if (owner && !mutex_spin_on_owner(lock, owner))
+		if (owner && !mutex_spin_on_owner(lock, owner, ww_ctx))
 			break;
 
 		/* Try to acquire the mutex if it is unlocked. */
-- 
2.8.1

[toc] | [next] | [standalone]

#1407509 — Re: [PATCH] mutex: Do not spin/queue before performing ww_mutex deadlock avoidance

Op 26-05-16 om 10:31 schreef Chris Wilson:
> The ww_mutex has the property of allowing the lock to detect and report
> when it may be used in deadlocking scenarios (to allow the caller to
> unwind its locks and avoid the deadlock). This detection needs to be
> performed before we queue up for the spin, otherwise we wait on the
> osq_lock() for our turn to detect the deadlock that another thread is
> spinning on, waiting for us. Otherwise as we are stuck behind our waiter,
> throughput plummets.
>
> This can be demonstrated by trying concurrent atomic modesets.
>
> Testcase: igt/kms_cursor_legacy
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: linux-kernel@vger.kernel.org
> ---
>  kernel/locking/mutex.c | 56 ++++++++++++++++++++++++++++++++------------------
>  1 file changed, 36 insertions(+), 20 deletions(-)
>
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index e364b424b019..d60f1ba3e64f 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -217,12 +217,35 @@ ww_mutex_set_context_slowpath(struct ww_mutex *lock,
>  }
>  
>  #ifdef CONFIG_MUTEX_SPIN_ON_OWNER
> +static bool ww_mutex_may_deadlock(struct mutex *lock,
> +				  struct ww_acquire_ctx *ww_ctx)
> +{
> +	if (ww_ctx && ww_ctx->acquired > 0) {
> +		struct ww_mutex *ww;
> +
> +		ww = container_of(lock, struct ww_mutex, base);
> +		/*
> +		 * If ww->ctx is set the contents are undefined, only
> +		 * by acquiring wait_lock there is a guarantee that
> +		 * they are not invalid when reading.
> +		 *
> +		 * As such, when deadlock detection needs to be
> +		 * performed the optimistic spinning cannot be done.
> +		 */
> +		if (READ_ONCE(ww->ctx))
> +			return true;
> +	}
> +
> +	return false;
> +}
The check should be at the beginning of __mutex_lock_common,
regardless of spin_on_owner.

This is because -EALREADY was originally designed to be exceptional,
but is used a lot by design in drm/atomic now.

The other check for -EALREADY can be killed, or changed to a
DEBUG_LOCKS_WARN_ON.

The check should also not be for NULL, but for use_ww_ctx.
This way the if check is optimized out for the ww_ctx path, where
ww_ctx is always non-null.

This would also be something for Cc: stable. :)

~Maarten

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

#1407514 — Re: [PATCH] mutex: Do not spin/queue before performing ww_mutex deadlock avoidance

On Thu, May 26, 2016 at 12:37:30PM +0200, Maarten Lankhorst wrote:
> The check should also not be for NULL, but for use_ww_ctx.
> This way the if check is optimized out for the ww_ctx path, where
> ww_ctx is always non-null.

The compiler can see use_ww_ctx == false => ww_ctx == NULL just as well
to do dead-code elimination, i.e. use_ww_ctx is superflouus and does not
reduce the code size. (gcc 4.7.2, 4.9.1, 5.3.1)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

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

#1407521 — Re: [PATCH] mutex: Do not spin/queue before performing ww_mutex deadlock avoidance

Op 26-05-16 om 12:43 schreef Chris Wilson:
> On Thu, May 26, 2016 at 12:37:30PM +0200, Maarten Lankhorst wrote:
>> The check should also not be for NULL, but for use_ww_ctx.
>> This way the if check is optimized out for the ww_ctx path, where
>> ww_ctx is always non-null.
> The compiler can see use_ww_ctx == false => ww_ctx == NULL just as well
> to do dead-code elimination, i.e. use_ww_ctx is superflouus and does not
> reduce the code size. (gcc 4.7.2, 4.9.1, 5.3.1)
That's true, but it cannot do the same when use_ww_ctx = true.
In this case the function will always be called with ww_ctx != NULL,
but the compiler can't see that, so it will keep the check even if it's always true.

~Maarten

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

#1407697 — [PATCH] mutex: Report recursive ww_mutex locking early

Recursive locking for ww_mutexes was originally conceived as an
exception. However, it is heavily used by the DRM atomic modesetting
code. Currently, the recursive deadlock is checked after we have queued
up for a busy-spin and as we never release the lock, we spin until
kicked, whereupon the deadlock is discovered and reported.

A simple solution for the now common problem is to move the recursive
deadlock discovery to the first action when taking the ww_mutex.

Testcase: igt/kms_cursor_legacy
Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: linux-kernel@vger.kernel.org
---

Maarten suggested this as a simpler fix to the immediate problem. Imo,
we still want to perform deadlock detection within the spin in order to
catch more complicated deadlocks without osq_lock() forcing fairness!
-Chris

---
 kernel/locking/mutex.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index d60f1ba3e64f..1659398dc8f8 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -502,9 +502,6 @@ __ww_mutex_lock_check_stamp(struct mutex *lock, struct ww_acquire_ctx *ctx)
 	if (!hold_ctx)
 		return 0;
 
-	if (unlikely(ctx == hold_ctx))
-		return -EALREADY;
-
 	if (ctx->stamp - hold_ctx->stamp <= LONG_MAX &&
 	    (ctx->stamp != hold_ctx->stamp || ctx > hold_ctx)) {
 #ifdef CONFIG_DEBUG_MUTEXES
@@ -530,6 +527,12 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 	unsigned long flags;
 	int ret;
 
+	if (use_ww_ctx) {
+		struct ww_mutex *ww = container_of(lock, struct ww_mutex, base);
+		if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
+			return -EALREADY;
+	}
+
 	preempt_disable();
 	mutex_acquire_nest(&lock->dep_map, subclass, 0, nest_lock, ip);
 
-- 
2.8.1

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

#1408829 — Re: [PATCH] mutex: Report recursive ww_mutex locking early

Op 26-05-16 om 22:08 schreef Chris Wilson:
> Recursive locking for ww_mutexes was originally conceived as an
> exception. However, it is heavily used by the DRM atomic modesetting
> code. Currently, the recursive deadlock is checked after we have queued
> up for a busy-spin and as we never release the lock, we spin until
> kicked, whereupon the deadlock is discovered and reported.
>
> A simple solution for the now common problem is to move the recursive
> deadlock discovery to the first action when taking the ww_mutex.
>
> Testcase: igt/kms_cursor_legacy
> Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: linux-kernel@vger.kernel.org
> ---
>
> Maarten suggested this as a simpler fix to the immediate problem. Imo,
> we still want to perform deadlock detection within the spin in order to
> catch more complicated deadlocks without osq_lock() forcing fairness!
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Should this be Cc: stable@vger.kernel.org ?

I think in the normal case things would move forward even with osq_lock,
but you can make a separate patch to add it to mutex_can_spin_on_owner,
with the same comment as in mutex_optimistic_spin.
> ---
>  kernel/locking/mutex.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index d60f1ba3e64f..1659398dc8f8 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -502,9 +502,6 @@ __ww_mutex_lock_check_stamp(struct mutex *lock, struct ww_acquire_ctx *ctx)
>  	if (!hold_ctx)
>  		return 0;
>  
> -	if (unlikely(ctx == hold_ctx))
> -		return -EALREADY;
> -
>  	if (ctx->stamp - hold_ctx->stamp <= LONG_MAX &&
>  	    (ctx->stamp != hold_ctx->stamp || ctx > hold_ctx)) {
>  #ifdef CONFIG_DEBUG_MUTEXES
> @@ -530,6 +527,12 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
>  	unsigned long flags;
>  	int ret;
>  
> +	if (use_ww_ctx) {
> +		struct ww_mutex *ww = container_of(lock, struct ww_mutex, base);
> +		if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
> +			return -EALREADY;
> +	}
> +
>  	preempt_disable();
>  	mutex_acquire_nest(&lock->dep_map, subclass, 0, nest_lock, ip);
>  

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

#1408917 — Re: [PATCH] mutex: Report recursive ww_mutex locking early

On Mon, May 30, 2016 at 09:43:53AM +0200, Maarten Lankhorst wrote:
> Op 26-05-16 om 22:08 schreef Chris Wilson:
> > Recursive locking for ww_mutexes was originally conceived as an
> > exception. However, it is heavily used by the DRM atomic modesetting
> > code. Currently, the recursive deadlock is checked after we have queued
> > up for a busy-spin and as we never release the lock, we spin until
> > kicked, whereupon the deadlock is discovered and reported.
> >
> > A simple solution for the now common problem is to move the recursive
> > deadlock discovery to the first action when taking the ww_mutex.
> >
> > Testcase: igt/kms_cursor_legacy

I've no idea what this tag is or where to find the actual testcase, so
I've killed it.

> > Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >
> > Maarten suggested this as a simpler fix to the immediate problem. Imo,
> > we still want to perform deadlock detection within the spin in order to
> > catch more complicated deadlocks without osq_lock() forcing fairness!
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> 
> Should this be Cc: stable@vger.kernel.org ?

Can do; how far back?

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

#1408947 — Re: [PATCH] mutex: Report recursive ww_mutex locking early

Op 30-05-16 om 11:11 schreef Peter Zijlstra:
> On Mon, May 30, 2016 at 09:43:53AM +0200, Maarten Lankhorst wrote:
>> Op 26-05-16 om 22:08 schreef Chris Wilson:
>>> Recursive locking for ww_mutexes was originally conceived as an
>>> exception. However, it is heavily used by the DRM atomic modesetting
>>> code. Currently, the recursive deadlock is checked after we have queued
>>> up for a busy-spin and as we never release the lock, we spin until
>>> kicked, whereupon the deadlock is discovered and reported.
>>>
>>> A simple solution for the now common problem is to move the recursive
>>> deadlock discovery to the first action when taking the ww_mutex.
>>>
>>> Testcase: igt/kms_cursor_legacy
> I've no idea what this tag is or where to find the actual testcase, so
> I've killed it.
https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

tests/kms_cursor_legacy tries to do as many updates as possible with SCHED_RR..

Patch not applied, SCHED_RR:
# ./kms_cursor_legacy 
IGT-Version: 1.14-g9579e5447aa3 (x86_64) (Linux: 4.6.0-patser+ x86_64)
[3] count=86
[2] count=91
[1] count=78
[0] count=104
Subtest stress-bo: SUCCESS (22,372s)

Patch not applied, SCHED_NORMAL:
# ./kms_cursor_legacy 
IGT-Version: 1.14-g9579e5447aa3 (x86_64) (Linux: 4.6.0-patser+ x86_64)
[2] count=4713
[0] count=4288
[3] count=4776
[1] count=4521
Subtest stress-bo: SUCCESS (21,492s)

Patch applied, NORMAL + RR give roughly same results:
# nfs/intel-gpu-tools/tests/kms_cursor_legacy 
IGT-Version: 1.14-g9579e5447aa3 (x86_64) (Linux: 4.6.0-patser+ x86_64)
[0] count=77631
[1] count=77740
[3] count=77612
[2] count=77666
Subtest stress-bo: SUCCESS (21,487s)

>>> Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Peter Zijlstra <peterz@infradead.org>
>>> Cc: Ingo Molnar <mingo@redhat.com>
>>> Cc: Christian König <christian.koenig@amd.com>
>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Cc: linux-kernel@vger.kernel.org
>>> ---
>>>
>>> Maarten suggested this as a simpler fix to the immediate problem. Imo,
>>> we still want to perform deadlock detection within the spin in order to
>>> catch more complicated deadlocks without osq_lock() forcing fairness!
>> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>
>> Should this be Cc: stable@vger.kernel.org ?
> Can do; how far back?
>

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

#1408969 — Re: [PATCH] mutex: Report recursive ww_mutex locking early

On Mon, May 30, 2016 at 11:43:31AM +0200, Maarten Lankhorst wrote:
> Patch not applied, SCHED_RR:

ww_mutex isn't RT aware at all; its one of the things I still have on a
todo list. Should I look harder at finding time for this?

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

#1408975 — Re: [PATCH] mutex: Report recursive ww_mutex locking early

On Mon, May 30, 2016 at 12:27:46PM +0200, Peter Zijlstra wrote:
> On Mon, May 30, 2016 at 11:43:31AM +0200, Maarten Lankhorst wrote:
> > Patch not applied, SCHED_RR:
> 
> ww_mutex isn't RT aware at all; its one of the things I still have on a
> todo list. Should I look harder at finding time for this?

The RT usage in the test is to just try and starve the kernel threads
that may be used behind the atomic modeset - a problem we have
encountered in the past. Afaik, no one is using ww_mutex from RT in the
wild, calling the atomic modeset from the RT was just a shortcut to
having the system fully populated with RT threads. To be more realistic
we should be using a couple of normal modesetting threads vs a set of RT
cpu hogs.

Otoh, i915.ko always draws the ire of rt-linux so ww_mutex is likely to
be in their sights in the near future (when i915.ko completes its
transition to full atomic modesetting).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

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

#1408992 — Re: [PATCH] mutex: Report recursive ww_mutex locking early

Op 30-05-16 om 12:45 schreef Chris Wilson:
> On Mon, May 30, 2016 at 12:27:46PM +0200, Peter Zijlstra wrote:
>> On Mon, May 30, 2016 at 11:43:31AM +0200, Maarten Lankhorst wrote:
>>> Patch not applied, SCHED_RR:
>> ww_mutex isn't RT aware at all; its one of the things I still have on a
>> todo list. Should I look harder at finding time for this?
> The RT usage in the test is to just try and starve the kernel threads
> that may be used behind the atomic modeset - a problem we have
> encountered in the past. Afaik, no one is using ww_mutex from RT in the
> wild, calling the atomic modeset from the RT was just a shortcut to
> having the system fully populated with RT threads. To be more realistic
> we should be using a couple of normal modesetting threads vs a set of RT
> cpu hogs.
Yeah, unfortunately this doesn't work as you intend it to. You'd need to spawn a few more threads at slightly lower priority so when a thread is blocked waiting for acquisition of the mutexes the workqueues still can't run.

ssh is still responsive with the rest running.
> Otoh, i915.ko always draws the ire of rt-linux so ww_mutex is likely to
> be in their sights in the near future (when i915.ko completes its
> transition to full atomic modesetting).

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web