All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH] rt/workqueue: assign the waiters higher priority to the workqueue thread
Date: Sat, 21 Feb 2009 06:02:54 +0100	[thread overview]
Message-ID: <499f8c5c.1185300a.4d42.ffff9404@mx.google.com> (raw)

When a work is embedeed inside the worklist of a barrier, it must check
the priority of more waiters than usual:

- the propagated higher priority of the barrier ancestors (the barrier in
  which our barrier parent is embedeed in)

- the priority of the task waiting for the completion of the barrier
  we are embedeed in

- the higher priority work which follows our barrier ancestor

But once this check is done, we forget to assign the higher priority
found and simply assign the priority of the current work to the current
workqueue thread, thus omitting the PI from all waiters.

This patch fixes it and also adds some comments, the current code is rather
complex.

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
---
 kernel/workqueue.c |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 90a54eb..e7ff441 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -325,17 +325,34 @@ again:
 		 */
 		struct lockdep_map lockdep_map = work->lockdep_map;
 #endif
+		/*
+		 * Iteration over each "waiter" priority to see which one
+		 * we have to inherit.
+		 */
 
+		/* Firstly: the current job */
 		prio = work->entry.prio;
+
+		/* In a barrier's worklist, we must handle yet other waiters */
 		if (unlikely(worklist != &cwq->worklist)) {
+			/*
+			 * If we are in a nested barrier, check the propagated
+			 * priority of the "grandfather" barrier waiting for us.
+			 */
 			prio = min(prio, cwq->barrier->prev_prio);
+
+			/* Check the task waiting for the parent barrier */
 			prio = min(prio, cwq->barrier->waiter_prio);
+
+			/* Check the higher priority work that follows the
+			 * ancestor barrier
+			 */
 			prio = min(prio, plist_first(&cwq->worklist)->prio);
 		}
 		prio = max(prio, 0);
 
 		if (likely(cwq->thread->prio != prio))
-			rt_mutex_setprio(cwq->thread, work->entry.prio);
+			rt_mutex_setprio(cwq->thread, prio);
 
 		cwq->current_work = work;
 		plist_del(&work->entry, worklist);
-- 
1.6.1



             reply	other threads:[~2009-02-21  5:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-21  5:02 Frederic Weisbecker [this message]
2009-02-21  5:25 ` [PATCH] rt/workqueue: assign the waiters higher priority to the workqueue thread Steven Rostedt

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=499f8c5c.1185300a.4d42.ffff9404@mx.google.com \
    --to=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.