mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Esben Nielsen <nielsen.esben@googlemail.com>
To: Esben Nielsen <nielsen.esben@gogglemail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Esben Nielsen <nielsen.esben@googlemail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org
Subject: Re: Why can't I set the priority of softirq-hrt? (Re: 2.6.17-rt1)
Date: Wed, 21 Jun 2006 16:43:48 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0606211638560.6572@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0606211204220.10723@localhost.localdomain>

On Wed, 21 Jun 2006, Esben Nielsen wrote:

>
>
> On Wed, 21 Jun 2006, Steven Rostedt wrote:
>
>>
>>  On Tue, 20 Jun 2006, Esben Nielsen wrote:
>> 
>> > 
>> > >  I have to check, whether the priority is propagated when the softirq 
>> > >  is
>> > >  blocked on a lock. If not its a bug and has to be fixed.
>> > 
>> >  I think the simplest solution would be to add
>> > 
>> >           if (p->blocked_on)
>> >                   wake_up_process(p);
>> > 
>> >  in __setscheduler().
>> > 
>>
>>  Except that wake_up_process calls try_to_wakeup which grabs the runqueue
>>  lock, which unfortunately is already held when __setscheduler is called.
>> 
>
> Yeah, I saw. Move it out in setscheduler() then. I'll try to fix it, but I am 
> not sure I can make a test if it works.

What about the patch below. It compiles and my UP labtop runs fine, but I 
haven't otherwise tested it.  My labtop runs RTExec without hichups 
until now.

Esben

Index: linux-2.6.17-rt1/kernel/rtmutex.c
===================================================================
--- linux-2.6.17-rt1.orig/kernel/rtmutex.c
+++ linux-2.6.17-rt1/kernel/rtmutex.c
@@ -625,6 +625,7 @@ rt_lock_slowlock(struct rt_mutex *lock _

  	debug_rt_mutex_init_waiter(&waiter);
  	waiter.task = NULL;
+	waiter.save_state = 1;

  	spin_lock(&lock->wait_lock);

@@ -687,6 +688,19 @@ rt_lock_slowlock(struct rt_mutex *lock _
  		state = xchg(&current->state, TASK_UNINTERRUPTIBLE);
  		if (unlikely(state == TASK_RUNNING))
  			saved_state = TASK_RUNNING;
+
+		if (unlikely(waiter.task) &&
+		    waiter.list_entry.prio != current->prio) {
+			/*
+			 * We still not have the lock, but we are woken up with
+			 * a different prio than the one we waited with
+			 * originally. We remove the wait entry now and then
+			 * reinsert ourselves with the right priority
+			 */
+			remove_waiter(lock, &waiter __IP__);
+			waiter.task = NULL;
+		}
+
  	}

  	state = xchg(&current->state, saved_state);
@@ -798,6 +812,7 @@ rt_mutex_slowlock(struct rt_mutex *lock,

  	debug_rt_mutex_init_waiter(&waiter);
  	waiter.task = NULL;
+	waiter.save_state = 0;

  	spin_lock(&lock->wait_lock);

@@ -877,6 +892,18 @@ rt_mutex_slowlock(struct rt_mutex *lock,

  		current->flags |= saved_flags;
  		set_current_state(state);
+
+		if (unlikely(waiter.task) &&
+		    waiter.list_entry.prio != current->prio) {
+			/*
+			 * We still not have the lock, but we are woken up with
+			 * a different prio than the one we waited with
+			 * originally. We remove the wait entry now and then
+			 * reinsert ourselves with the right priority
+			 */
+			remove_waiter(lock, &waiter __IP__);
+			waiter.task = NULL;
+		}
  	}

  	set_current_state(TASK_RUNNING);
Index: linux-2.6.17-rt1/kernel/sched.c
===================================================================
--- linux-2.6.17-rt1.orig/kernel/sched.c
+++ linux-2.6.17-rt1/kernel/sched.c
@@ -57,6 +57,8 @@

  #include <asm/unistd.h>

+#include "rtmutex_common.h"
+
  /*
   * Convert user-nice values [ -20 ... 0 ... 19 ]
   * to static priority [ MAX_RT_PRIO..MAX_PRIO-1 ],
@@ -646,7 +648,9 @@ static inline void sched_info_switch(tas
  #define sched_info_switch(t, next)	do { } while (0)
  #endif /* CONFIG_SCHEDSTATS */

+#ifdef CONFIG_SMP
  static __cacheline_aligned_in_smp atomic_t rt_overload;
+#endif

  static inline void inc_rt_tasks(task_t *p, runqueue_t *rq)
  {
@@ -1473,10 +1477,11 @@ static inline int wake_idle(int cpu, tas
  static int try_to_wake_up(task_t *p, unsigned int state, int sync, int mutex)
  {
  	int cpu, this_cpu, success = 0;
-	runqueue_t *this_rq, *rq;
+	runqueue_t *rq;
  	unsigned long flags;
  	long old_state;
  #ifdef CONFIG_SMP
+	runqueue_t *this_rq;
  	unsigned long load, this_load;
  	struct sched_domain *sd, *this_sd = NULL;
  	int new_cpu;
@@ -4351,6 +4356,18 @@ int setscheduler(struct task_struct *p,
  			resched_task(rq->curr);
  	}
  	task_rq_unlock(rq, &flags);
+
+	/*
+	 * If the process is blocked on rt-mutex, it will now wake up and
+	 * reinsert itself into the wait list and boost the owner correctly
+	 */
+	if (p->pi_blocked_on) {
+		if (p->pi_blocked_on->save_state)
+			wake_up_process_mutex(p);
+		else
+			wake_up_process(p);
+	}
+
  	spin_unlock_irqrestore(&p->pi_lock, fp);
  	return 0;
  }
@@ -7086,4 +7103,3 @@ void notrace preempt_enable_no_resched(v

  EXPORT_SYMBOL(preempt_enable_no_resched);
  #endif
-
Index: linux-2.6.17-rt1/kernel/rtmutex_common.h
===================================================================
--- linux-2.6.17-rt1.orig/kernel/rtmutex_common.h
+++ linux-2.6.17-rt1/kernel/rtmutex_common.h
@@ -49,6 +49,7 @@ struct rt_mutex_waiter {
  	struct plist_node	pi_list_entry;
  	struct task_struct	*task;
  	struct rt_mutex		*lock;
+	int                     save_state;
  #ifdef CONFIG_DEBUG_RT_MUTEXES
  	unsigned long		ip;
  	pid_t			deadlock_task_pid;

  reply	other threads:[~2006-06-21 14:43 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-18  7:06 2.6.17-rt1 Ingo Molnar
2006-06-18 16:13 ` 2.6.17-rt1 Michal Piotrowski
     [not found] ` <Pine.LNX.4.64.0606201656230.11643@localhost.localdomain>
2006-06-20 15:13   ` Why can't I set the priority of softirq-hrt? (Re: 2.6.17-rt1) Thomas Gleixner
2006-06-20 17:09     ` Esben Nielsen
2006-06-20 16:35       ` Thomas Gleixner
2006-06-20 21:16         ` Esben Nielsen
2006-06-20 20:35           ` Thomas Gleixner
2006-06-20 23:19             ` Esben Nielsen
2006-06-20 16:39       ` Steven Rostedt
2006-06-20 18:12         ` Esben Nielsen
2006-06-20 17:21           ` Thomas Gleixner
2006-06-20 21:26             ` Esben Nielsen
2006-06-20 20:51               ` Thomas Gleixner
2006-06-21  8:20               ` Steven Rostedt
2006-06-21 11:05                 ` Esben Nielsen
2006-06-21 15:43                   ` Esben Nielsen [this message]
2006-06-21 15:21                     ` Steven Rostedt
2006-06-21 16:37                       ` Esben Nielsen
2006-06-21 15:51                         ` Steven Rostedt
2006-06-21 17:14                           ` Esben Nielsen
2006-06-21 16:26                     ` Thomas Gleixner
2006-06-21 18:30                       ` Ingo Molnar
2006-06-22 10:28                         ` Esben Nielsen
2006-06-21 21:29                       ` Esben Nielsen
2006-06-21 20:33                         ` Thomas Gleixner
2006-06-21 23:35                           ` Esben Nielsen
2006-06-22  7:06                             ` Thomas Gleixner
2006-06-22 10:32                               ` Esben Nielsen
2006-06-22 13:33                               ` Steven Rostedt
2006-06-22 13:45                       ` Steven Rostedt
2006-06-22 14:20                         ` Thomas Gleixner
2006-06-22 14:23                           ` Steven Rostedt
2006-06-22 14:26                             ` Thomas Gleixner
2006-06-22 18:06                               ` Esben Nielsen
2006-06-22 18:05                                 ` Thomas Gleixner
2006-06-23 11:23                                   ` Esben Nielsen
2006-06-23 11:06                                     ` Steven Rostedt
2006-07-03 11:48                                     ` Esben Nielsen
2006-06-21  8:13           ` Steven Rostedt
2006-06-21 11:03             ` Esben Nielsen
2006-06-22  0:57 ` 2.6.17-rt1 Lee Revell
2006-06-22  2:51   ` More weird latency trace output (was Re: 2.6.17-rt1) Lee Revell
2006-06-23  1:24     ` Lee Revell
2006-06-24 22:15       ` Lee Revell
2006-06-24 22:12         ` Ingo Molnar
2006-06-24 22:31           ` Lee Revell
2006-06-24 23:49           ` Lee Revell
2006-06-23 20:56 ` 2.6.17-rt1 - mm_struct leak Vernon Mauery
2006-06-24  9:24   ` Mark Hounschell
2006-06-24  9:32     ` Mark Hounschell
2006-06-30 16:02   ` [PATCH -RT]Re: " Vernon Mauery

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=Pine.LNX.4.64.0606211638560.6572@localhost.localdomain \
    --to=nielsen.esben@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nielsen.esben@gogglemail.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®