2006-06-27 17:54:53 +08:00
|
|
|
/*
|
|
|
|
* RT-Mutexes: simple blocking mutual exclusion locks with PI support
|
|
|
|
*
|
|
|
|
* started by Ingo Molnar and Thomas Gleixner.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2004-2006 Red Hat, Inc., Ingo Molnar <mingo@redhat.com>
|
|
|
|
* Copyright (C) 2005-2006 Timesys Corp., Thomas Gleixner <tglx@timesys.com>
|
|
|
|
* Copyright (C) 2005 Kihon Technologies Inc., Steven Rostedt
|
|
|
|
* Copyright (C) 2006 Esben Nielsen
|
2006-07-30 18:04:03 +08:00
|
|
|
*
|
|
|
|
* See Documentation/rt-mutex-design.txt for details.
|
2006-06-27 17:54:53 +08:00
|
|
|
*/
|
|
|
|
#include <linux/spinlock.h>
|
2011-05-24 02:51:41 +08:00
|
|
|
#include <linux/export.h>
|
2006-06-27 17:54:53 +08:00
|
|
|
#include <linux/sched.h>
|
2013-02-07 23:47:07 +08:00
|
|
|
#include <linux/sched/rt.h>
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
#include <linux/sched/deadline.h>
|
2006-06-27 17:54:53 +08:00
|
|
|
#include <linux/timer.h>
|
|
|
|
|
|
|
|
#include "rtmutex_common.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* lock->owner state tracking:
|
|
|
|
*
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
* lock->owner holds the task_struct pointer of the owner. Bit 0
|
|
|
|
* is used to keep track of the "lock has waiters" state.
|
2006-06-27 17:54:53 +08:00
|
|
|
*
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
* owner bit0
|
|
|
|
* NULL 0 lock is free (fast acquire possible)
|
|
|
|
* NULL 1 lock is free and has waiters and the top waiter
|
|
|
|
* is going to take the lock*
|
|
|
|
* taskpointer 0 lock is held (fast release possible)
|
|
|
|
* taskpointer 1 lock is held and has waiters**
|
2006-06-27 17:54:53 +08:00
|
|
|
*
|
|
|
|
* The fast atomic compare exchange based acquire and release is only
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
* possible when bit 0 of lock->owner is 0.
|
|
|
|
*
|
|
|
|
* (*) It also can be a transitional state when grabbing the lock
|
|
|
|
* with ->wait_lock is held. To prevent any fast path cmpxchg to the lock,
|
|
|
|
* we need to set the bit0 before looking at the lock, and the owner may be
|
|
|
|
* NULL in this small time, hence this can be a transitional state.
|
2006-06-27 17:54:53 +08:00
|
|
|
*
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
* (**) There is a small time when bit 0 is set but there are no
|
|
|
|
* waiters. This can happen when grabbing the lock in the slow path.
|
|
|
|
* To prevent a cmpxchg of the owner releasing the lock, we need to
|
|
|
|
* set this bit before looking at the lock.
|
2006-06-27 17:54:53 +08:00
|
|
|
*/
|
|
|
|
|
2007-06-18 03:11:10 +08:00
|
|
|
static void
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
rt_mutex_set_owner(struct rt_mutex *lock, struct task_struct *owner)
|
2006-06-27 17:54:53 +08:00
|
|
|
{
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
unsigned long val = (unsigned long)owner;
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
if (rt_mutex_has_waiters(lock))
|
|
|
|
val |= RT_MUTEX_HAS_WAITERS;
|
|
|
|
|
|
|
|
lock->owner = (struct task_struct *)val;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void clear_rt_mutex_waiters(struct rt_mutex *lock)
|
|
|
|
{
|
|
|
|
lock->owner = (struct task_struct *)
|
|
|
|
((unsigned long)lock->owner & ~RT_MUTEX_HAS_WAITERS);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void fixup_rt_mutex_waiters(struct rt_mutex *lock)
|
|
|
|
{
|
|
|
|
if (!rt_mutex_has_waiters(lock))
|
|
|
|
clear_rt_mutex_waiters(lock);
|
|
|
|
}
|
|
|
|
|
2007-06-18 03:11:10 +08:00
|
|
|
/*
|
|
|
|
* We can speed up the acquire/release, if the architecture
|
|
|
|
* supports cmpxchg and if there's no debugging state to be set up
|
|
|
|
*/
|
|
|
|
#if defined(__HAVE_ARCH_CMPXCHG) && !defined(CONFIG_DEBUG_RT_MUTEXES)
|
|
|
|
# define rt_mutex_cmpxchg(l,c,n) (cmpxchg(&l->owner, c, n) == c)
|
|
|
|
static inline void mark_rt_mutex_waiters(struct rt_mutex *lock)
|
|
|
|
{
|
|
|
|
unsigned long owner, *p = (unsigned long *) &lock->owner;
|
|
|
|
|
|
|
|
do {
|
|
|
|
owner = *p;
|
|
|
|
} while (cmpxchg(p, owner, owner | RT_MUTEX_HAS_WAITERS) != owner);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
# define rt_mutex_cmpxchg(l,c,n) (0)
|
|
|
|
static inline void mark_rt_mutex_waiters(struct rt_mutex *lock)
|
|
|
|
{
|
|
|
|
lock->owner = (struct task_struct *)
|
|
|
|
((unsigned long)lock->owner | RT_MUTEX_HAS_WAITERS);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
static inline int
|
|
|
|
rt_mutex_waiter_less(struct rt_mutex_waiter *left,
|
|
|
|
struct rt_mutex_waiter *right)
|
|
|
|
{
|
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:44 +08:00
|
|
|
if (left->prio < right->prio)
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
/*
|
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:44 +08:00
|
|
|
* If both waiters have dl_prio(), we check the deadlines of the
|
|
|
|
* associated tasks.
|
|
|
|
* If left waiter has a dl_prio(), and we didn't return 1 above,
|
|
|
|
* then right waiter has a dl_prio() too.
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
*/
|
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:44 +08:00
|
|
|
if (dl_prio(left->prio))
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
return (left->task->dl.deadline < right->task->dl.deadline);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
rt_mutex_enqueue(struct rt_mutex *lock, struct rt_mutex_waiter *waiter)
|
|
|
|
{
|
|
|
|
struct rb_node **link = &lock->waiters.rb_node;
|
|
|
|
struct rb_node *parent = NULL;
|
|
|
|
struct rt_mutex_waiter *entry;
|
|
|
|
int leftmost = 1;
|
|
|
|
|
|
|
|
while (*link) {
|
|
|
|
parent = *link;
|
|
|
|
entry = rb_entry(parent, struct rt_mutex_waiter, tree_entry);
|
|
|
|
if (rt_mutex_waiter_less(waiter, entry)) {
|
|
|
|
link = &parent->rb_left;
|
|
|
|
} else {
|
|
|
|
link = &parent->rb_right;
|
|
|
|
leftmost = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (leftmost)
|
|
|
|
lock->waiters_leftmost = &waiter->tree_entry;
|
|
|
|
|
|
|
|
rb_link_node(&waiter->tree_entry, parent, link);
|
|
|
|
rb_insert_color(&waiter->tree_entry, &lock->waiters);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
rt_mutex_dequeue(struct rt_mutex *lock, struct rt_mutex_waiter *waiter)
|
|
|
|
{
|
|
|
|
if (RB_EMPTY_NODE(&waiter->tree_entry))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (lock->waiters_leftmost == &waiter->tree_entry)
|
|
|
|
lock->waiters_leftmost = rb_next(&waiter->tree_entry);
|
|
|
|
|
|
|
|
rb_erase(&waiter->tree_entry, &lock->waiters);
|
|
|
|
RB_CLEAR_NODE(&waiter->tree_entry);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
rt_mutex_enqueue_pi(struct task_struct *task, struct rt_mutex_waiter *waiter)
|
|
|
|
{
|
|
|
|
struct rb_node **link = &task->pi_waiters.rb_node;
|
|
|
|
struct rb_node *parent = NULL;
|
|
|
|
struct rt_mutex_waiter *entry;
|
|
|
|
int leftmost = 1;
|
|
|
|
|
|
|
|
while (*link) {
|
|
|
|
parent = *link;
|
|
|
|
entry = rb_entry(parent, struct rt_mutex_waiter, pi_tree_entry);
|
|
|
|
if (rt_mutex_waiter_less(waiter, entry)) {
|
|
|
|
link = &parent->rb_left;
|
|
|
|
} else {
|
|
|
|
link = &parent->rb_right;
|
|
|
|
leftmost = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (leftmost)
|
|
|
|
task->pi_waiters_leftmost = &waiter->pi_tree_entry;
|
|
|
|
|
|
|
|
rb_link_node(&waiter->pi_tree_entry, parent, link);
|
|
|
|
rb_insert_color(&waiter->pi_tree_entry, &task->pi_waiters);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
rt_mutex_dequeue_pi(struct task_struct *task, struct rt_mutex_waiter *waiter)
|
|
|
|
{
|
|
|
|
if (RB_EMPTY_NODE(&waiter->pi_tree_entry))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (task->pi_waiters_leftmost == &waiter->pi_tree_entry)
|
|
|
|
task->pi_waiters_leftmost = rb_next(&waiter->pi_tree_entry);
|
|
|
|
|
|
|
|
rb_erase(&waiter->pi_tree_entry, &task->pi_waiters);
|
|
|
|
RB_CLEAR_NODE(&waiter->pi_tree_entry);
|
|
|
|
}
|
|
|
|
|
2006-06-27 17:54:53 +08:00
|
|
|
/*
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
* Calculate task priority from the waiter tree priority
|
2006-06-27 17:54:53 +08:00
|
|
|
*
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
* Return task->normal_prio when the waiter tree is empty or when
|
2006-06-27 17:54:53 +08:00
|
|
|
* the waiter is not allowed to do priority boosting
|
|
|
|
*/
|
|
|
|
int rt_mutex_getprio(struct task_struct *task)
|
|
|
|
{
|
|
|
|
if (likely(!task_has_pi_waiters(task)))
|
|
|
|
return task->normal_prio;
|
|
|
|
|
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:44 +08:00
|
|
|
return min(task_top_pi_waiter(task)->prio,
|
2006-06-27 17:54:53 +08:00
|
|
|
task->normal_prio);
|
|
|
|
}
|
|
|
|
|
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:44 +08:00
|
|
|
struct task_struct *rt_mutex_get_top_task(struct task_struct *task)
|
|
|
|
{
|
|
|
|
if (likely(!task_has_pi_waiters(task)))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return task_top_pi_waiter(task)->task;
|
|
|
|
}
|
|
|
|
|
2014-02-08 03:58:42 +08:00
|
|
|
/*
|
|
|
|
* Called by sched_setscheduler() to check whether the priority change
|
|
|
|
* is overruled by a possible priority boosting.
|
|
|
|
*/
|
|
|
|
int rt_mutex_check_prio(struct task_struct *task, int newprio)
|
|
|
|
{
|
|
|
|
if (!task_has_pi_waiters(task))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return task_top_pi_waiter(task)->task->prio <= newprio;
|
|
|
|
}
|
|
|
|
|
2006-06-27 17:54:53 +08:00
|
|
|
/*
|
|
|
|
* Adjust the priority of a task, after its pi_waiters got modified.
|
|
|
|
*
|
|
|
|
* This can be both boosting and unboosting. task->pi_lock must be held.
|
|
|
|
*/
|
2007-06-18 03:11:10 +08:00
|
|
|
static void __rt_mutex_adjust_prio(struct task_struct *task)
|
2006-06-27 17:54:53 +08:00
|
|
|
{
|
|
|
|
int prio = rt_mutex_getprio(task);
|
|
|
|
|
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:44 +08:00
|
|
|
if (task->prio != prio || dl_prio(prio))
|
2006-06-27 17:54:53 +08:00
|
|
|
rt_mutex_setprio(task, prio);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Adjust task priority (undo boosting). Called from the exit path of
|
|
|
|
* rt_mutex_slowunlock() and rt_mutex_slowlock().
|
|
|
|
*
|
|
|
|
* (Note: We do this outside of the protection of lock->wait_lock to
|
|
|
|
* allow the lock to be taken while or before we readjust the priority
|
|
|
|
* of task. We do not use the spin_xx_mutex() variants here as we are
|
|
|
|
* outside of the debug path.)
|
|
|
|
*/
|
|
|
|
static void rt_mutex_adjust_prio(struct task_struct *task)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_lock_irqsave(&task->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
__rt_mutex_adjust_prio(task);
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Max number of times we'll walk the boosting chain:
|
|
|
|
*/
|
|
|
|
int max_lock_depth = 1024;
|
|
|
|
|
2014-06-05 17:16:12 +08:00
|
|
|
static inline struct rt_mutex *task_blocked_on_lock(struct task_struct *p)
|
|
|
|
{
|
|
|
|
return p->pi_blocked_on ? p->pi_blocked_on->lock : NULL;
|
|
|
|
}
|
|
|
|
|
2006-06-27 17:54:53 +08:00
|
|
|
/*
|
|
|
|
* Adjust the priority chain. Also used for deadlock detection.
|
|
|
|
* Decreases task's usage by one - may thus free the task.
|
2013-05-15 17:04:10 +08:00
|
|
|
*
|
2014-06-05 17:16:12 +08:00
|
|
|
* @task: the task owning the mutex (owner) for which a chain walk is
|
|
|
|
* probably needed
|
2013-05-15 17:04:10 +08:00
|
|
|
* @deadlock_detect: do we have to carry out deadlock detection?
|
2014-06-05 17:16:12 +08:00
|
|
|
* @orig_lock: the mutex (can be NULL if we are walking the chain to recheck
|
|
|
|
* things for a task that has just got its priority adjusted, and
|
|
|
|
* is waiting on a mutex)
|
|
|
|
* @next_lock: the mutex on which the owner of @orig_lock was blocked before
|
|
|
|
* we dropped its pi_lock. Is never dereferenced, only used for
|
|
|
|
* comparison to detect lock chain changes.
|
2013-05-15 17:04:10 +08:00
|
|
|
* @orig_waiter: rt_mutex_waiter struct for the task that has just donated
|
2014-06-05 17:16:12 +08:00
|
|
|
* its priority to the mutex owner (can be NULL in the case
|
|
|
|
* depicted above or if the top waiter is gone away and we are
|
|
|
|
* actually deboosting the owner)
|
|
|
|
* @top_task: the current top waiter
|
2013-05-15 17:04:10 +08:00
|
|
|
*
|
2006-06-27 17:54:53 +08:00
|
|
|
* Returns 0 or -EDEADLK.
|
|
|
|
*/
|
2007-06-18 03:11:10 +08:00
|
|
|
static int rt_mutex_adjust_prio_chain(struct task_struct *task,
|
|
|
|
int deadlock_detect,
|
|
|
|
struct rt_mutex *orig_lock,
|
2014-06-05 17:16:12 +08:00
|
|
|
struct rt_mutex *next_lock,
|
2007-06-18 03:11:10 +08:00
|
|
|
struct rt_mutex_waiter *orig_waiter,
|
|
|
|
struct task_struct *top_task)
|
2006-06-27 17:54:53 +08:00
|
|
|
{
|
|
|
|
struct rt_mutex *lock;
|
|
|
|
struct rt_mutex_waiter *waiter, *top_waiter = orig_waiter;
|
|
|
|
int detect_deadlock, ret = 0, depth = 0;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
detect_deadlock = debug_rt_mutex_detect_deadlock(orig_waiter,
|
|
|
|
deadlock_detect);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The (de)boosting is a step by step approach with a lot of
|
|
|
|
* pitfalls. We want this to be preemptible and we want hold a
|
|
|
|
* maximum of two locks per step. So we have to check
|
|
|
|
* carefully whether things change under us.
|
|
|
|
*/
|
|
|
|
again:
|
|
|
|
if (++depth > max_lock_depth) {
|
|
|
|
static int prev_max;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Print this only once. If the admin changes the limit,
|
|
|
|
* print a new message when reaching the limit again.
|
|
|
|
*/
|
|
|
|
if (prev_max != max_lock_depth) {
|
|
|
|
prev_max = max_lock_depth;
|
|
|
|
printk(KERN_WARNING "Maximum lock depth %d reached "
|
|
|
|
"task: %s (%d)\n", max_lock_depth,
|
2007-10-19 14:40:40 +08:00
|
|
|
top_task->comm, task_pid_nr(top_task));
|
2006-06-27 17:54:53 +08:00
|
|
|
}
|
|
|
|
put_task_struct(task);
|
|
|
|
|
2014-06-05 18:34:23 +08:00
|
|
|
return -EDEADLK;
|
2006-06-27 17:54:53 +08:00
|
|
|
}
|
|
|
|
retry:
|
|
|
|
/*
|
|
|
|
* Task can not go away as we did a get_task() before !
|
|
|
|
*/
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_lock_irqsave(&task->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
waiter = task->pi_blocked_on;
|
|
|
|
/*
|
|
|
|
* Check whether the end of the boosting chain has been
|
|
|
|
* reached or the state of the chain has changed while we
|
|
|
|
* dropped the locks.
|
|
|
|
*/
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
if (!waiter)
|
2006-06-27 17:54:53 +08:00
|
|
|
goto out_unlock_pi;
|
|
|
|
|
2007-06-09 04:46:58 +08:00
|
|
|
/*
|
|
|
|
* Check the orig_waiter state. After we dropped the locks,
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
* the previous owner of the lock might have released the lock.
|
2007-06-09 04:46:58 +08:00
|
|
|
*/
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
if (orig_waiter && !rt_mutex_owner(orig_lock))
|
2007-06-09 04:46:58 +08:00
|
|
|
goto out_unlock_pi;
|
|
|
|
|
2014-06-05 17:16:12 +08:00
|
|
|
/*
|
|
|
|
* We dropped all locks after taking a refcount on @task, so
|
|
|
|
* the task might have moved on in the lock chain or even left
|
|
|
|
* the chain completely and blocks now on an unrelated lock or
|
|
|
|
* on @orig_lock.
|
|
|
|
*
|
|
|
|
* We stored the lock on which @task was blocked in @next_lock,
|
|
|
|
* so we can detect the chain change.
|
|
|
|
*/
|
|
|
|
if (next_lock != waiter->lock)
|
|
|
|
goto out_unlock_pi;
|
|
|
|
|
2007-06-09 04:46:58 +08:00
|
|
|
/*
|
|
|
|
* Drop out, when the task has no waiters. Note,
|
|
|
|
* top_waiter can be NULL, when we are in the deboosting
|
|
|
|
* mode!
|
|
|
|
*/
|
2014-05-22 11:25:39 +08:00
|
|
|
if (top_waiter) {
|
|
|
|
if (!task_has_pi_waiters(task))
|
|
|
|
goto out_unlock_pi;
|
|
|
|
/*
|
|
|
|
* If deadlock detection is off, we stop here if we
|
|
|
|
* are not the top pi waiter of the task.
|
|
|
|
*/
|
|
|
|
if (!detect_deadlock && top_waiter != task_top_pi_waiter(task))
|
|
|
|
goto out_unlock_pi;
|
|
|
|
}
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* When deadlock detection is off then we check, if further
|
|
|
|
* priority adjustment is necessary.
|
|
|
|
*/
|
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:44 +08:00
|
|
|
if (!detect_deadlock && waiter->prio == task->prio)
|
2006-06-27 17:54:53 +08:00
|
|
|
goto out_unlock_pi;
|
|
|
|
|
|
|
|
lock = waiter->lock;
|
2009-11-18 01:22:11 +08:00
|
|
|
if (!raw_spin_trylock(&lock->wait_lock)) {
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
cpu_relax();
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
|
2014-05-22 11:25:39 +08:00
|
|
|
/*
|
|
|
|
* Deadlock detection. If the lock is the same as the original
|
|
|
|
* lock which caused us to walk the lock chain or if the
|
|
|
|
* current lock is owned by the task which initiated the chain
|
|
|
|
* walk, we detected a deadlock.
|
|
|
|
*/
|
2006-06-27 17:55:02 +08:00
|
|
|
if (lock == orig_lock || rt_mutex_owner(lock) == top_task) {
|
2006-06-27 17:54:53 +08:00
|
|
|
debug_rt_mutex_deadlock(deadlock_detect, orig_waiter, lock);
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2014-06-05 18:34:23 +08:00
|
|
|
ret = -EDEADLK;
|
2006-06-27 17:54:53 +08:00
|
|
|
goto out_unlock_pi;
|
|
|
|
}
|
|
|
|
|
|
|
|
top_waiter = rt_mutex_top_waiter(lock);
|
|
|
|
|
|
|
|
/* Requeue the waiter */
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_dequeue(lock, waiter);
|
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:44 +08:00
|
|
|
waiter->prio = task->prio;
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_enqueue(lock, waiter);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
/* Release the task */
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
if (!rt_mutex_owner(lock)) {
|
|
|
|
/*
|
|
|
|
* If the requeue above changed the top waiter, then we need
|
|
|
|
* to wake the new top waiter up to try to get the lock.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (top_waiter != rt_mutex_top_waiter(lock))
|
|
|
|
wake_up_process(rt_mutex_top_waiter(lock)->task);
|
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
|
|
|
goto out_put_task;
|
|
|
|
}
|
2006-06-27 17:54:53 +08:00
|
|
|
put_task_struct(task);
|
|
|
|
|
|
|
|
/* Grab the next task */
|
|
|
|
task = rt_mutex_owner(lock);
|
2006-09-29 16:59:44 +08:00
|
|
|
get_task_struct(task);
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_lock_irqsave(&task->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
if (waiter == rt_mutex_top_waiter(lock)) {
|
|
|
|
/* Boost the owner */
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_dequeue_pi(task, top_waiter);
|
|
|
|
rt_mutex_enqueue_pi(task, waiter);
|
2006-06-27 17:54:53 +08:00
|
|
|
__rt_mutex_adjust_prio(task);
|
|
|
|
|
|
|
|
} else if (top_waiter == waiter) {
|
|
|
|
/* Deboost the owner */
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_dequeue_pi(task, waiter);
|
2006-06-27 17:54:53 +08:00
|
|
|
waiter = rt_mutex_top_waiter(lock);
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_enqueue_pi(task, waiter);
|
2006-06-27 17:54:53 +08:00
|
|
|
__rt_mutex_adjust_prio(task);
|
|
|
|
}
|
|
|
|
|
2014-06-05 17:16:12 +08:00
|
|
|
/*
|
|
|
|
* Check whether the task which owns the current lock is pi
|
|
|
|
* blocked itself. If yes we store a pointer to the lock for
|
|
|
|
* the lock chain change detection above. After we dropped
|
|
|
|
* task->pi_lock next_lock cannot be dereferenced anymore.
|
|
|
|
*/
|
|
|
|
next_lock = task_blocked_on_lock(task);
|
|
|
|
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
top_waiter = rt_mutex_top_waiter(lock);
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
2014-06-05 17:16:12 +08:00
|
|
|
/*
|
|
|
|
* We reached the end of the lock chain. Stop right here. No
|
|
|
|
* point to go back just to figure that out.
|
|
|
|
*/
|
|
|
|
if (!next_lock)
|
|
|
|
goto out_put_task;
|
|
|
|
|
2006-06-27 17:54:53 +08:00
|
|
|
if (!detect_deadlock && waiter != top_waiter)
|
|
|
|
goto out_put_task;
|
|
|
|
|
|
|
|
goto again;
|
|
|
|
|
|
|
|
out_unlock_pi:
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
out_put_task:
|
|
|
|
put_task_struct(task);
|
2006-07-03 15:25:41 +08:00
|
|
|
|
2006-06-27 17:54:53 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to take an rt-mutex
|
|
|
|
*
|
|
|
|
* Must be called with lock->wait_lock held.
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
*
|
|
|
|
* @lock: the lock to be acquired.
|
|
|
|
* @task: the task which wants to acquire the lock
|
|
|
|
* @waiter: the waiter that is queued to the lock's wait list. (could be NULL)
|
2006-06-27 17:54:53 +08:00
|
|
|
*/
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
static int try_to_take_rt_mutex(struct rt_mutex *lock, struct task_struct *task,
|
|
|
|
struct rt_mutex_waiter *waiter)
|
2006-06-27 17:54:53 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We have to be careful here if the atomic speedups are
|
|
|
|
* enabled, such that, when
|
|
|
|
* - no other waiter is on the lock
|
|
|
|
* - the lock has been released since we did the cmpxchg
|
|
|
|
* the lock can be released or taken while we are doing the
|
|
|
|
* checks and marking the lock with RT_MUTEX_HAS_WAITERS.
|
|
|
|
*
|
|
|
|
* The atomic acquire/release aware variant of
|
|
|
|
* mark_rt_mutex_waiters uses a cmpxchg loop. After setting
|
|
|
|
* the WAITERS bit, the atomic release / acquire can not
|
|
|
|
* happen anymore and lock->wait_lock protects us from the
|
|
|
|
* non-atomic case.
|
|
|
|
*
|
|
|
|
* Note, that this might set lock->owner =
|
|
|
|
* RT_MUTEX_HAS_WAITERS in the case the lock is not contended
|
|
|
|
* any more. This is fixed up when we take the ownership.
|
|
|
|
* This is the transitional state explained at the top of this file.
|
|
|
|
*/
|
|
|
|
mark_rt_mutex_waiters(lock);
|
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
if (rt_mutex_owner(lock))
|
2006-06-27 17:54:53 +08:00
|
|
|
return 0;
|
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
/*
|
|
|
|
* It will get the lock because of one of these conditions:
|
|
|
|
* 1) there is no waiter
|
|
|
|
* 2) higher priority than waiters
|
|
|
|
* 3) it is top waiter
|
|
|
|
*/
|
|
|
|
if (rt_mutex_has_waiters(lock)) {
|
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:44 +08:00
|
|
|
if (task->prio >= rt_mutex_top_waiter(lock)->prio) {
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
if (!waiter || waiter != rt_mutex_top_waiter(lock))
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (waiter || rt_mutex_has_waiters(lock)) {
|
|
|
|
unsigned long flags;
|
|
|
|
struct rt_mutex_waiter *top;
|
|
|
|
|
|
|
|
raw_spin_lock_irqsave(&task->pi_lock, flags);
|
|
|
|
|
|
|
|
/* remove the queued waiter. */
|
|
|
|
if (waiter) {
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_dequeue(lock, waiter);
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
task->pi_blocked_on = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We have to enqueue the top waiter(if it exists) into
|
|
|
|
* task->pi_waiters list.
|
|
|
|
*/
|
|
|
|
if (rt_mutex_has_waiters(lock)) {
|
|
|
|
top = rt_mutex_top_waiter(lock);
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_enqueue_pi(task, top);
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
}
|
|
|
|
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
|
|
|
|
}
|
|
|
|
|
2006-06-27 17:54:53 +08:00
|
|
|
/* We got the lock. */
|
2006-07-03 15:24:33 +08:00
|
|
|
debug_rt_mutex_lock(lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
rt_mutex_set_owner(lock, task);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
rt_mutex_deadlock_account_lock(lock, task);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Task blocks on lock.
|
|
|
|
*
|
|
|
|
* Prepare waiter and propagate pi chain
|
|
|
|
*
|
|
|
|
* This must be called with lock->wait_lock held.
|
|
|
|
*/
|
|
|
|
static int task_blocks_on_rt_mutex(struct rt_mutex *lock,
|
|
|
|
struct rt_mutex_waiter *waiter,
|
2009-04-04 04:40:12 +08:00
|
|
|
struct task_struct *task,
|
2006-07-03 15:24:33 +08:00
|
|
|
int detect_deadlock)
|
2006-06-27 17:54:53 +08:00
|
|
|
{
|
2006-07-03 15:25:41 +08:00
|
|
|
struct task_struct *owner = rt_mutex_owner(lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
struct rt_mutex_waiter *top_waiter = waiter;
|
2014-06-05 17:16:12 +08:00
|
|
|
struct rt_mutex *next_lock;
|
2006-09-29 16:59:44 +08:00
|
|
|
int chain_walk = 0, res;
|
2014-06-05 17:16:12 +08:00
|
|
|
unsigned long flags;
|
2006-06-27 17:54:53 +08:00
|
|
|
|
2014-05-22 11:25:39 +08:00
|
|
|
/*
|
|
|
|
* Early deadlock detection. We really don't want the task to
|
|
|
|
* enqueue on itself just to untangle the mess later. It's not
|
|
|
|
* only an optimization. We drop the locks, so another waiter
|
|
|
|
* can come in before the chain walk detects the deadlock. So
|
|
|
|
* the other will detect the deadlock and return -EDEADLOCK,
|
|
|
|
* which is wrong, as the other waiter is not in a deadlock
|
|
|
|
* situation.
|
|
|
|
*/
|
2014-06-05 18:34:23 +08:00
|
|
|
if (owner == task)
|
2014-05-22 11:25:39 +08:00
|
|
|
return -EDEADLK;
|
|
|
|
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_lock_irqsave(&task->pi_lock, flags);
|
2009-04-04 04:40:12 +08:00
|
|
|
__rt_mutex_adjust_prio(task);
|
|
|
|
waiter->task = task;
|
2006-06-27 17:54:53 +08:00
|
|
|
waiter->lock = lock;
|
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:44 +08:00
|
|
|
waiter->prio = task->prio;
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
/* Get the top priority waiter on the lock */
|
|
|
|
if (rt_mutex_has_waiters(lock))
|
|
|
|
top_waiter = rt_mutex_top_waiter(lock);
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_enqueue(lock, waiter);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
2009-04-04 04:40:12 +08:00
|
|
|
task->pi_blocked_on = waiter;
|
2006-06-27 17:54:53 +08:00
|
|
|
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
if (!owner)
|
|
|
|
return 0;
|
|
|
|
|
2014-06-05 17:16:12 +08:00
|
|
|
raw_spin_lock_irqsave(&owner->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
if (waiter == rt_mutex_top_waiter(lock)) {
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_dequeue_pi(owner, top_waiter);
|
|
|
|
rt_mutex_enqueue_pi(owner, waiter);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
__rt_mutex_adjust_prio(owner);
|
2006-09-29 16:59:44 +08:00
|
|
|
if (owner->pi_blocked_on)
|
|
|
|
chain_walk = 1;
|
2014-06-05 17:16:12 +08:00
|
|
|
} else if (debug_rt_mutex_detect_deadlock(waiter, detect_deadlock)) {
|
2006-09-29 16:59:44 +08:00
|
|
|
chain_walk = 1;
|
2014-06-05 17:16:12 +08:00
|
|
|
}
|
2006-09-29 16:59:44 +08:00
|
|
|
|
2014-06-05 17:16:12 +08:00
|
|
|
/* Store the lock on which owner is blocked or NULL */
|
|
|
|
next_lock = task_blocked_on_lock(owner);
|
|
|
|
|
|
|
|
raw_spin_unlock_irqrestore(&owner->pi_lock, flags);
|
|
|
|
/*
|
|
|
|
* Even if full deadlock detection is on, if the owner is not
|
|
|
|
* blocked itself, we can avoid finding this out in the chain
|
|
|
|
* walk.
|
|
|
|
*/
|
|
|
|
if (!chain_walk || !next_lock)
|
2006-06-27 17:54:53 +08:00
|
|
|
return 0;
|
|
|
|
|
2006-09-29 16:59:44 +08:00
|
|
|
/*
|
|
|
|
* The owner can't disappear while holding a lock,
|
|
|
|
* so the owner struct is protected by wait_lock.
|
|
|
|
* Gets dropped in rt_mutex_adjust_prio_chain()!
|
|
|
|
*/
|
|
|
|
get_task_struct(owner);
|
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
2014-06-05 17:16:12 +08:00
|
|
|
res = rt_mutex_adjust_prio_chain(owner, detect_deadlock, lock,
|
|
|
|
next_lock, waiter, task);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_lock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wake up the next waiter on the lock.
|
|
|
|
*
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
* Remove the top waiter from the current tasks waiter list and wake it up.
|
2006-06-27 17:54:53 +08:00
|
|
|
*
|
|
|
|
* Called with lock->wait_lock held.
|
|
|
|
*/
|
|
|
|
static void wakeup_next_waiter(struct rt_mutex *lock)
|
|
|
|
{
|
|
|
|
struct rt_mutex_waiter *waiter;
|
|
|
|
unsigned long flags;
|
|
|
|
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_lock_irqsave(¤t->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
waiter = rt_mutex_top_waiter(lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove it from current->pi_waiters. We do not adjust a
|
|
|
|
* possible priority boost right now. We execute wakeup in the
|
|
|
|
* boosted mode and go back to normal after releasing
|
|
|
|
* lock->wait_lock.
|
|
|
|
*/
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_dequeue_pi(current, waiter);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
rt_mutex_set_owner(lock, NULL);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_unlock_irqrestore(¤t->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
wake_up_process(waiter->task);
|
2006-06-27 17:54:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
* Remove a waiter from a lock and give up
|
2006-06-27 17:54:53 +08:00
|
|
|
*
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
* Must be called with lock->wait_lock held and
|
|
|
|
* have just failed to try_to_take_rt_mutex().
|
2006-06-27 17:54:53 +08:00
|
|
|
*/
|
2007-06-18 03:11:10 +08:00
|
|
|
static void remove_waiter(struct rt_mutex *lock,
|
|
|
|
struct rt_mutex_waiter *waiter)
|
2006-06-27 17:54:53 +08:00
|
|
|
{
|
|
|
|
int first = (waiter == rt_mutex_top_waiter(lock));
|
2006-07-03 15:25:41 +08:00
|
|
|
struct task_struct *owner = rt_mutex_owner(lock);
|
2014-06-05 17:16:12 +08:00
|
|
|
struct rt_mutex *next_lock = NULL;
|
2006-06-27 17:54:53 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_lock_irqsave(¤t->pi_lock, flags);
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_dequeue(lock, waiter);
|
2006-06-27 17:54:53 +08:00
|
|
|
current->pi_blocked_on = NULL;
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_unlock_irqrestore(¤t->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
if (!owner)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (first) {
|
2006-06-27 17:54:53 +08:00
|
|
|
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_lock_irqsave(&owner->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_dequeue_pi(owner, waiter);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
if (rt_mutex_has_waiters(lock)) {
|
|
|
|
struct rt_mutex_waiter *next;
|
|
|
|
|
|
|
|
next = rt_mutex_top_waiter(lock);
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
rt_mutex_enqueue_pi(owner, next);
|
2006-06-27 17:54:53 +08:00
|
|
|
}
|
|
|
|
__rt_mutex_adjust_prio(owner);
|
|
|
|
|
2014-06-05 17:16:12 +08:00
|
|
|
/* Store the lock on which owner is blocked or NULL */
|
|
|
|
next_lock = task_blocked_on_lock(owner);
|
2006-09-29 16:59:44 +08:00
|
|
|
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_unlock_irqrestore(&owner->pi_lock, flags);
|
2006-06-27 17:54:53 +08:00
|
|
|
}
|
|
|
|
|
2014-06-05 17:16:12 +08:00
|
|
|
if (!next_lock)
|
2006-06-27 17:54:53 +08:00
|
|
|
return;
|
|
|
|
|
2006-09-29 16:59:44 +08:00
|
|
|
/* gets dropped in rt_mutex_adjust_prio_chain()! */
|
|
|
|
get_task_struct(owner);
|
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
2014-06-05 17:16:12 +08:00
|
|
|
rt_mutex_adjust_prio_chain(owner, 0, lock, next_lock, NULL, current);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_lock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
}
|
|
|
|
|
2006-06-27 17:55:02 +08:00
|
|
|
/*
|
|
|
|
* Recheck the pi chain, in case we got a priority setting
|
|
|
|
*
|
|
|
|
* Called from sched_setscheduler
|
|
|
|
*/
|
|
|
|
void rt_mutex_adjust_pi(struct task_struct *task)
|
|
|
|
{
|
|
|
|
struct rt_mutex_waiter *waiter;
|
2014-06-05 17:16:12 +08:00
|
|
|
struct rt_mutex *next_lock;
|
2006-06-27 17:55:02 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_lock_irqsave(&task->pi_lock, flags);
|
2006-06-27 17:55:02 +08:00
|
|
|
|
|
|
|
waiter = task->pi_blocked_on;
|
sched/deadline: Add SCHED_DEADLINE inheritance logic
Some method to deal with rt-mutexes and make sched_dl interact with
the current PI-coded is needed, raising all but trivial issues, that
needs (according to us) to be solved with some restructuring of
the pi-code (i.e., going toward a proxy execution-ish implementation).
This is under development, in the meanwhile, as a temporary solution,
what this commits does is:
- ensure a pi-lock owner with waiters is never throttled down. Instead,
when it runs out of runtime, it immediately gets replenished and it's
deadline is postponed;
- the scheduling parameters (relative deadline and default runtime)
used for that replenishments --during the whole period it holds the
pi-lock-- are the ones of the waiting task with earliest deadline.
Acting this way, we provide some kind of boosting to the lock-owner,
still by using the existing (actually, slightly modified by the previous
commit) pi-architecture.
We would stress the fact that this is only a surely needed, all but
clean solution to the problem. In the end it's only a way to re-start
discussion within the community. So, as always, comments, ideas, rants,
etc.. are welcome! :-)
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
[ Added !RT_MUTEXES build fix. ]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:44 +08:00
|
|
|
if (!waiter || (waiter->prio == task->prio &&
|
|
|
|
!dl_prio(task->prio))) {
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
|
2006-06-27 17:55:02 +08:00
|
|
|
return;
|
|
|
|
}
|
2014-06-05 17:16:12 +08:00
|
|
|
next_lock = waiter->lock;
|
2009-11-17 21:54:03 +08:00
|
|
|
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
|
2006-06-27 17:55:02 +08:00
|
|
|
|
2006-09-29 16:59:44 +08:00
|
|
|
/* gets dropped in rt_mutex_adjust_prio_chain()! */
|
|
|
|
get_task_struct(task);
|
2014-06-05 17:16:12 +08:00
|
|
|
|
|
|
|
rt_mutex_adjust_prio_chain(task, 0, NULL, next_lock, NULL, task);
|
2006-06-27 17:55:02 +08:00
|
|
|
}
|
|
|
|
|
2009-04-04 04:40:12 +08:00
|
|
|
/**
|
|
|
|
* __rt_mutex_slowlock() - Perform the wait-wake-try-to-take loop
|
|
|
|
* @lock: the rt_mutex to take
|
|
|
|
* @state: the state the task should block in (TASK_INTERRUPTIBLE
|
|
|
|
* or TASK_UNINTERRUPTIBLE)
|
|
|
|
* @timeout: the pre-initialized and started timer, or NULL for none
|
|
|
|
* @waiter: the pre-initialized rt_mutex_waiter
|
|
|
|
*
|
|
|
|
* lock->wait_lock must be held by the caller.
|
2006-06-27 17:54:53 +08:00
|
|
|
*/
|
|
|
|
static int __sched
|
2009-04-04 04:40:12 +08:00
|
|
|
__rt_mutex_slowlock(struct rt_mutex *lock, int state,
|
|
|
|
struct hrtimer_sleeper *timeout,
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
struct rt_mutex_waiter *waiter)
|
2006-06-27 17:54:53 +08:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
/* Try to acquire the lock: */
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
if (try_to_take_rt_mutex(lock, current, waiter))
|
2006-06-27 17:54:53 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* TASK_INTERRUPTIBLE checks for signals and
|
|
|
|
* timeout. Ignored otherwise.
|
|
|
|
*/
|
|
|
|
if (unlikely(state == TASK_INTERRUPTIBLE)) {
|
|
|
|
/* Signal pending? */
|
|
|
|
if (signal_pending(current))
|
|
|
|
ret = -EINTR;
|
|
|
|
if (timeout && !timeout->task)
|
|
|
|
ret = -ETIMEDOUT;
|
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
2009-04-04 04:40:12 +08:00
|
|
|
debug_rt_mutex_print_deadlock(waiter);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
schedule_rt_mutex(lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_lock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
set_current_state(state);
|
|
|
|
}
|
|
|
|
|
2009-04-04 04:40:12 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-06-05 18:34:23 +08:00
|
|
|
static void rt_mutex_handle_deadlock(int res, int detect_deadlock,
|
|
|
|
struct rt_mutex_waiter *w)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If the result is not -EDEADLOCK or the caller requested
|
|
|
|
* deadlock detection, nothing to do here.
|
|
|
|
*/
|
|
|
|
if (res != -EDEADLOCK || detect_deadlock)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Yell lowdly and stop the task right here.
|
|
|
|
*/
|
|
|
|
rt_mutex_print_deadlock(w);
|
|
|
|
while (1) {
|
|
|
|
set_current_state(TASK_INTERRUPTIBLE);
|
|
|
|
schedule();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-04-04 04:40:12 +08:00
|
|
|
/*
|
|
|
|
* Slow path lock function:
|
|
|
|
*/
|
|
|
|
static int __sched
|
|
|
|
rt_mutex_slowlock(struct rt_mutex *lock, int state,
|
|
|
|
struct hrtimer_sleeper *timeout,
|
|
|
|
int detect_deadlock)
|
|
|
|
{
|
|
|
|
struct rt_mutex_waiter waiter;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
debug_rt_mutex_init_waiter(&waiter);
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
RB_CLEAR_NODE(&waiter.pi_tree_entry);
|
|
|
|
RB_CLEAR_NODE(&waiter.tree_entry);
|
2009-04-04 04:40:12 +08:00
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_lock(&lock->wait_lock);
|
2009-04-04 04:40:12 +08:00
|
|
|
|
|
|
|
/* Try to acquire the lock again: */
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
if (try_to_take_rt_mutex(lock, current, NULL)) {
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2009-04-04 04:40:12 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
set_current_state(state);
|
|
|
|
|
|
|
|
/* Setup the timer, when timeout != NULL */
|
|
|
|
if (unlikely(timeout)) {
|
|
|
|
hrtimer_start_expires(&timeout->timer, HRTIMER_MODE_ABS);
|
|
|
|
if (!hrtimer_active(&timeout->timer))
|
|
|
|
timeout->task = NULL;
|
|
|
|
}
|
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
ret = task_blocks_on_rt_mutex(lock, &waiter, current, detect_deadlock);
|
|
|
|
|
|
|
|
if (likely(!ret))
|
|
|
|
ret = __rt_mutex_slowlock(lock, state, timeout, &waiter);
|
2009-04-04 04:40:12 +08:00
|
|
|
|
2006-06-27 17:54:53 +08:00
|
|
|
set_current_state(TASK_RUNNING);
|
|
|
|
|
2014-06-05 18:34:23 +08:00
|
|
|
if (unlikely(ret)) {
|
2006-07-03 15:24:33 +08:00
|
|
|
remove_waiter(lock, &waiter);
|
2014-06-05 18:34:23 +08:00
|
|
|
rt_mutex_handle_deadlock(ret, detect_deadlock, &waiter);
|
|
|
|
}
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* try_to_take_rt_mutex() sets the waiter bit
|
|
|
|
* unconditionally. We might have to fix that up.
|
|
|
|
*/
|
|
|
|
fixup_rt_mutex_waiters(lock);
|
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
/* Remove pending timer: */
|
|
|
|
if (unlikely(timeout))
|
|
|
|
hrtimer_cancel(&timeout->timer);
|
|
|
|
|
|
|
|
debug_rt_mutex_free_waiter(&waiter);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Slow path try-lock function:
|
|
|
|
*/
|
|
|
|
static inline int
|
2006-07-03 15:24:33 +08:00
|
|
|
rt_mutex_slowtrylock(struct rt_mutex *lock)
|
2006-06-27 17:54:53 +08:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_lock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
if (likely(rt_mutex_owner(lock) != current)) {
|
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
ret = try_to_take_rt_mutex(lock, current, NULL);
|
2006-06-27 17:54:53 +08:00
|
|
|
/*
|
|
|
|
* try_to_take_rt_mutex() sets the lock waiters
|
|
|
|
* bit unconditionally. Clean this up.
|
|
|
|
*/
|
|
|
|
fixup_rt_mutex_waiters(lock);
|
|
|
|
}
|
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Slow path to release a rt-mutex:
|
|
|
|
*/
|
|
|
|
static void __sched
|
|
|
|
rt_mutex_slowunlock(struct rt_mutex *lock)
|
|
|
|
{
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_lock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
debug_rt_mutex_unlock(lock);
|
|
|
|
|
|
|
|
rt_mutex_deadlock_account_unlock(current);
|
|
|
|
|
|
|
|
if (!rt_mutex_has_waiters(lock)) {
|
|
|
|
lock->owner = NULL;
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
wakeup_next_waiter(lock);
|
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
/* Undo pi boosting if necessary: */
|
|
|
|
rt_mutex_adjust_prio(current);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* debug aware fast / slowpath lock,trylock,unlock
|
|
|
|
*
|
|
|
|
* The atomic acquire/release ops are compiled away, when either the
|
|
|
|
* architecture does not support cmpxchg or when debugging is enabled.
|
|
|
|
*/
|
|
|
|
static inline int
|
|
|
|
rt_mutex_fastlock(struct rt_mutex *lock, int state,
|
|
|
|
int detect_deadlock,
|
|
|
|
int (*slowfn)(struct rt_mutex *lock, int state,
|
|
|
|
struct hrtimer_sleeper *timeout,
|
2006-07-03 15:24:33 +08:00
|
|
|
int detect_deadlock))
|
2006-06-27 17:54:53 +08:00
|
|
|
{
|
|
|
|
if (!detect_deadlock && likely(rt_mutex_cmpxchg(lock, NULL, current))) {
|
|
|
|
rt_mutex_deadlock_account_lock(lock, current);
|
|
|
|
return 0;
|
|
|
|
} else
|
2006-07-03 15:24:33 +08:00
|
|
|
return slowfn(lock, state, NULL, detect_deadlock);
|
2006-06-27 17:54:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
rt_mutex_timed_fastlock(struct rt_mutex *lock, int state,
|
|
|
|
struct hrtimer_sleeper *timeout, int detect_deadlock,
|
|
|
|
int (*slowfn)(struct rt_mutex *lock, int state,
|
|
|
|
struct hrtimer_sleeper *timeout,
|
2006-07-03 15:24:33 +08:00
|
|
|
int detect_deadlock))
|
2006-06-27 17:54:53 +08:00
|
|
|
{
|
|
|
|
if (!detect_deadlock && likely(rt_mutex_cmpxchg(lock, NULL, current))) {
|
|
|
|
rt_mutex_deadlock_account_lock(lock, current);
|
|
|
|
return 0;
|
|
|
|
} else
|
2006-07-03 15:24:33 +08:00
|
|
|
return slowfn(lock, state, timeout, detect_deadlock);
|
2006-06-27 17:54:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
rt_mutex_fasttrylock(struct rt_mutex *lock,
|
2006-07-03 15:24:33 +08:00
|
|
|
int (*slowfn)(struct rt_mutex *lock))
|
2006-06-27 17:54:53 +08:00
|
|
|
{
|
|
|
|
if (likely(rt_mutex_cmpxchg(lock, NULL, current))) {
|
|
|
|
rt_mutex_deadlock_account_lock(lock, current);
|
|
|
|
return 1;
|
|
|
|
}
|
2006-07-03 15:24:33 +08:00
|
|
|
return slowfn(lock);
|
2006-06-27 17:54:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
rt_mutex_fastunlock(struct rt_mutex *lock,
|
|
|
|
void (*slowfn)(struct rt_mutex *lock))
|
|
|
|
{
|
|
|
|
if (likely(rt_mutex_cmpxchg(lock, current, NULL)))
|
|
|
|
rt_mutex_deadlock_account_unlock(current);
|
|
|
|
else
|
|
|
|
slowfn(lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rt_mutex_lock - lock a rt_mutex
|
|
|
|
*
|
|
|
|
* @lock: the rt_mutex to be locked
|
|
|
|
*/
|
|
|
|
void __sched rt_mutex_lock(struct rt_mutex *lock)
|
|
|
|
{
|
|
|
|
might_sleep();
|
|
|
|
|
|
|
|
rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, 0, rt_mutex_slowlock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rt_mutex_lock);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rt_mutex_lock_interruptible - lock a rt_mutex interruptible
|
|
|
|
*
|
|
|
|
* @lock: the rt_mutex to be locked
|
|
|
|
* @detect_deadlock: deadlock detection on/off
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* 0 on success
|
|
|
|
* -EINTR when interrupted by a signal
|
|
|
|
* -EDEADLK when the lock would deadlock (when deadlock detection is on)
|
|
|
|
*/
|
|
|
|
int __sched rt_mutex_lock_interruptible(struct rt_mutex *lock,
|
|
|
|
int detect_deadlock)
|
|
|
|
{
|
|
|
|
might_sleep();
|
|
|
|
|
|
|
|
return rt_mutex_fastlock(lock, TASK_INTERRUPTIBLE,
|
|
|
|
detect_deadlock, rt_mutex_slowlock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rt_mutex_lock_interruptible);
|
|
|
|
|
|
|
|
/**
|
2009-04-30 04:54:51 +08:00
|
|
|
* rt_mutex_timed_lock - lock a rt_mutex interruptible
|
|
|
|
* the timeout structure is provided
|
|
|
|
* by the caller
|
2006-06-27 17:54:53 +08:00
|
|
|
*
|
|
|
|
* @lock: the rt_mutex to be locked
|
|
|
|
* @timeout: timeout structure or NULL (no timeout)
|
|
|
|
* @detect_deadlock: deadlock detection on/off
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* 0 on success
|
|
|
|
* -EINTR when interrupted by a signal
|
2009-06-04 22:20:28 +08:00
|
|
|
* -ETIMEDOUT when the timeout expired
|
2006-06-27 17:54:53 +08:00
|
|
|
* -EDEADLK when the lock would deadlock (when deadlock detection is on)
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
rt_mutex_timed_lock(struct rt_mutex *lock, struct hrtimer_sleeper *timeout,
|
|
|
|
int detect_deadlock)
|
|
|
|
{
|
|
|
|
might_sleep();
|
|
|
|
|
|
|
|
return rt_mutex_timed_fastlock(lock, TASK_INTERRUPTIBLE, timeout,
|
|
|
|
detect_deadlock, rt_mutex_slowlock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rt_mutex_timed_lock);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rt_mutex_trylock - try to lock a rt_mutex
|
|
|
|
*
|
|
|
|
* @lock: the rt_mutex to be locked
|
|
|
|
*
|
|
|
|
* Returns 1 on success and 0 on contention
|
|
|
|
*/
|
|
|
|
int __sched rt_mutex_trylock(struct rt_mutex *lock)
|
|
|
|
{
|
|
|
|
return rt_mutex_fasttrylock(lock, rt_mutex_slowtrylock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rt_mutex_trylock);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rt_mutex_unlock - unlock a rt_mutex
|
|
|
|
*
|
|
|
|
* @lock: the rt_mutex to be unlocked
|
|
|
|
*/
|
|
|
|
void __sched rt_mutex_unlock(struct rt_mutex *lock)
|
|
|
|
{
|
|
|
|
rt_mutex_fastunlock(lock, rt_mutex_slowunlock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rt_mutex_unlock);
|
|
|
|
|
2009-04-30 04:54:51 +08:00
|
|
|
/**
|
2006-06-27 17:54:53 +08:00
|
|
|
* rt_mutex_destroy - mark a mutex unusable
|
|
|
|
* @lock: the mutex to be destroyed
|
|
|
|
*
|
|
|
|
* This function marks the mutex uninitialized, and any subsequent
|
|
|
|
* use of the mutex is forbidden. The mutex must not be locked when
|
|
|
|
* this function is called.
|
|
|
|
*/
|
|
|
|
void rt_mutex_destroy(struct rt_mutex *lock)
|
|
|
|
{
|
|
|
|
WARN_ON(rt_mutex_is_locked(lock));
|
|
|
|
#ifdef CONFIG_DEBUG_RT_MUTEXES
|
|
|
|
lock->magic = NULL;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(rt_mutex_destroy);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __rt_mutex_init - initialize the rt lock
|
|
|
|
*
|
|
|
|
* @lock: the rt lock to be initialized
|
|
|
|
*
|
|
|
|
* Initialize the rt lock to unlocked state.
|
|
|
|
*
|
|
|
|
* Initializing of a locked rt lock is not allowed
|
|
|
|
*/
|
|
|
|
void __rt_mutex_init(struct rt_mutex *lock, const char *name)
|
|
|
|
{
|
|
|
|
lock->owner = NULL;
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_lock_init(&lock->wait_lock);
|
rtmutex: Turn the plist into an rb-tree
Turn the pi-chains from plist to rb-tree, in the rt_mutex code,
and provide a proper comparison function for -deadline and
-priority tasks.
This is done mainly because:
- classical prio field of the plist is just an int, which might
not be enough for representing a deadline;
- manipulating such a list would become O(nr_deadline_tasks),
which might be to much, as the number of -deadline task increases.
Therefore, an rb-tree is used, and tasks are queued in it according
to the following logic:
- among two -priority (i.e., SCHED_BATCH/OTHER/RR/FIFO) tasks, the
one with the higher (lower, actually!) prio wins;
- among a -priority and a -deadline task, the latter always wins;
- among two -deadline tasks, the one with the earliest deadline
wins.
Queueing and dequeueing functions are changed accordingly, for both
the list of a task's pi-waiters and the list of tasks blocked on
a pi-lock.
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-again-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1383831828-15501-10-git-send-email-juri.lelli@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-07 21:43:43 +08:00
|
|
|
lock->waiters = RB_ROOT;
|
|
|
|
lock->waiters_leftmost = NULL;
|
2006-06-27 17:54:53 +08:00
|
|
|
|
|
|
|
debug_rt_mutex_init(lock, name);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__rt_mutex_init);
|
2006-06-27 17:54:57 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* rt_mutex_init_proxy_locked - initialize and lock a rt_mutex on behalf of a
|
|
|
|
* proxy owner
|
|
|
|
*
|
|
|
|
* @lock: the rt_mutex to be locked
|
|
|
|
* @proxy_owner:the task to set as owner
|
|
|
|
*
|
|
|
|
* No locking. Caller has to do serializing itself
|
|
|
|
* Special API call for PI-futex support
|
|
|
|
*/
|
|
|
|
void rt_mutex_init_proxy_locked(struct rt_mutex *lock,
|
|
|
|
struct task_struct *proxy_owner)
|
|
|
|
{
|
|
|
|
__rt_mutex_init(lock, NULL);
|
2006-07-03 15:24:33 +08:00
|
|
|
debug_rt_mutex_proxy_lock(lock, proxy_owner);
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
rt_mutex_set_owner(lock, proxy_owner);
|
2006-06-27 17:54:57 +08:00
|
|
|
rt_mutex_deadlock_account_lock(lock, proxy_owner);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rt_mutex_proxy_unlock - release a lock on behalf of owner
|
|
|
|
*
|
|
|
|
* @lock: the rt_mutex to be locked
|
|
|
|
*
|
|
|
|
* No locking. Caller has to do serializing itself
|
|
|
|
* Special API call for PI-futex support
|
|
|
|
*/
|
|
|
|
void rt_mutex_proxy_unlock(struct rt_mutex *lock,
|
|
|
|
struct task_struct *proxy_owner)
|
|
|
|
{
|
|
|
|
debug_rt_mutex_proxy_unlock(lock);
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
rt_mutex_set_owner(lock, NULL);
|
2006-06-27 17:54:57 +08:00
|
|
|
rt_mutex_deadlock_account_unlock(proxy_owner);
|
|
|
|
}
|
|
|
|
|
2009-04-04 04:40:12 +08:00
|
|
|
/**
|
|
|
|
* rt_mutex_start_proxy_lock() - Start lock acquisition for another task
|
|
|
|
* @lock: the rt_mutex to take
|
|
|
|
* @waiter: the pre-initialized rt_mutex_waiter
|
|
|
|
* @task: the task to prepare
|
|
|
|
* @detect_deadlock: perform deadlock detection (1) or not (0)
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* 0 - task blocked on lock
|
|
|
|
* 1 - acquired the lock for task, caller should wake it up
|
|
|
|
* <0 - error
|
|
|
|
*
|
|
|
|
* Special API call for FUTEX_REQUEUE_PI support.
|
|
|
|
*/
|
|
|
|
int rt_mutex_start_proxy_lock(struct rt_mutex *lock,
|
|
|
|
struct rt_mutex_waiter *waiter,
|
|
|
|
struct task_struct *task, int detect_deadlock)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_lock(&lock->wait_lock);
|
2009-04-04 04:40:12 +08:00
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
if (try_to_take_rt_mutex(lock, task, NULL)) {
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2009-04-04 04:40:12 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2014-06-05 18:34:23 +08:00
|
|
|
/* We enforce deadlock detection for futexes */
|
|
|
|
ret = task_blocks_on_rt_mutex(lock, waiter, task, 1);
|
2009-04-04 04:40:12 +08:00
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
if (ret && !rt_mutex_owner(lock)) {
|
2009-04-04 04:40:12 +08:00
|
|
|
/*
|
|
|
|
* Reset the return value. We might have
|
|
|
|
* returned with -EDEADLK and the owner
|
|
|
|
* released the lock while we were walking the
|
|
|
|
* pi chain. Let the waiter sort it out.
|
|
|
|
*/
|
|
|
|
ret = 0;
|
|
|
|
}
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
|
|
|
|
if (unlikely(ret))
|
|
|
|
remove_waiter(lock, waiter);
|
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2009-04-04 04:40:12 +08:00
|
|
|
|
|
|
|
debug_rt_mutex_print_deadlock(waiter);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2006-06-27 17:54:57 +08:00
|
|
|
/**
|
|
|
|
* rt_mutex_next_owner - return the next owner of the lock
|
|
|
|
*
|
|
|
|
* @lock: the rt lock query
|
|
|
|
*
|
|
|
|
* Returns the next owner of the lock or NULL
|
|
|
|
*
|
|
|
|
* Caller has to serialize against other accessors to the lock
|
|
|
|
* itself.
|
|
|
|
*
|
|
|
|
* Special API call for PI-futex support
|
|
|
|
*/
|
|
|
|
struct task_struct *rt_mutex_next_owner(struct rt_mutex *lock)
|
|
|
|
{
|
|
|
|
if (!rt_mutex_has_waiters(lock))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return rt_mutex_top_waiter(lock)->task;
|
|
|
|
}
|
2009-04-04 04:40:12 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* rt_mutex_finish_proxy_lock() - Complete lock acquisition
|
|
|
|
* @lock: the rt_mutex we were woken on
|
|
|
|
* @to: the timeout, null if none. hrtimer should already have
|
|
|
|
* been started.
|
|
|
|
* @waiter: the pre-initialized rt_mutex_waiter
|
|
|
|
* @detect_deadlock: perform deadlock detection (1) or not (0)
|
|
|
|
*
|
|
|
|
* Complete the lock acquisition started our behalf by another thread.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* 0 - success
|
|
|
|
* <0 - error, one of -EINTR, -ETIMEDOUT, or -EDEADLK
|
|
|
|
*
|
|
|
|
* Special API call for PI-futex requeue support
|
|
|
|
*/
|
|
|
|
int rt_mutex_finish_proxy_lock(struct rt_mutex *lock,
|
|
|
|
struct hrtimer_sleeper *to,
|
|
|
|
struct rt_mutex_waiter *waiter,
|
|
|
|
int detect_deadlock)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_lock(&lock->wait_lock);
|
2009-04-04 04:40:12 +08:00
|
|
|
|
|
|
|
set_current_state(TASK_INTERRUPTIBLE);
|
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
ret = __rt_mutex_slowlock(lock, TASK_INTERRUPTIBLE, to, waiter);
|
2009-04-04 04:40:12 +08:00
|
|
|
|
|
|
|
set_current_state(TASK_RUNNING);
|
|
|
|
|
rtmutex: Simplify PI algorithm and make highest prio task get lock
In current rtmutex, the pending owner may be boosted by the tasks
in the rtmutex's waitlist when the pending owner is deboosted
or a task in the waitlist is boosted. This boosting is unrelated,
because the pending owner does not really take the rtmutex.
It is not reasonable.
Example.
time1:
A(high prio) onwers the rtmutex.
B(mid prio) and C (low prio) in the waitlist.
time2
A release the lock, B becomes the pending owner
A(or other high prio task) continues to run. B's prio is lower
than A, so B is just queued at the runqueue.
time3
A or other high prio task sleeps, but we have passed some time
The B and C's prio are changed in the period (time2 ~ time3)
due to boosting or deboosting. Now C has the priority higher
than B. ***Is it reasonable that C has to boost B and help B to
get the rtmutex?
NO!! I think, it is unrelated/unneed boosting before B really
owns the rtmutex. We should give C a chance to beat B and
win the rtmutex.
This is the motivation of this patch. This patch *ensures*
only the top waiter or higher priority task can take the lock.
How?
1) we don't dequeue the top waiter when unlock, if the top waiter
is changed, the old top waiter will fail and go to sleep again.
2) when requiring lock, it will get the lock when the lock is not taken and:
there is no waiter OR higher priority than waiters OR it is top waiter.
3) In any time, the top waiter is changed, the top waiter will be woken up.
The algorithm is much simpler than before, no pending owner, no
boosting for pending owner.
Other advantage of this patch:
1) The states of a rtmutex are reduced a half, easier to read the code.
2) the codes become shorter.
3) top waiter is not dequeued until it really take the lock:
they will retain FIFO when it is stolen.
Not advantage nor disadvantage
1) Even we may wakeup multiple waiters(any time when top waiter changed),
we hardly cause "thundering herd",
the number of wokenup task is likely 1 or very little.
2) two APIs are changed.
rt_mutex_owner() will not return pending owner, it will return NULL when
the top waiter is going to take the lock.
rt_mutex_next_owner() always return the top waiter.
will not return NULL if we have waiters
because the top waiter is not dequeued.
I have fixed the code that use these APIs.
need updated after this patch is accepted
1) Document/*
2) the testcase scripts/rt-tester/t4-l2-pi-deboost.tst
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D3012D5.4060709@cn.fujitsu.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-01-14 17:09:41 +08:00
|
|
|
if (unlikely(ret))
|
2009-04-04 04:40:12 +08:00
|
|
|
remove_waiter(lock, waiter);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* try_to_take_rt_mutex() sets the waiter bit unconditionally. We might
|
|
|
|
* have to fix that up.
|
|
|
|
*/
|
|
|
|
fixup_rt_mutex_waiters(lock);
|
|
|
|
|
2009-11-18 01:22:11 +08:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2009-04-04 04:40:12 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|