2013-02-07 08:47:07 -07:00
|
|
|
#ifndef _SCHED_RT_H
|
|
|
|
|
#define _SCHED_RT_H
|
|
|
|
|
|
2014-01-27 15:15:37 -07:00
|
|
|
#include <linux/sched/prio.h>
|
2013-02-07 08:47:07 -07:00
|
|
|
|
|
|
|
|
static inline int rt_prio(int prio)
|
|
|
|
|
{
|
|
|
|
|
if (unlikely(prio < MAX_RT_PRIO))
|
|
|
|
|
return 1;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int rt_task(struct task_struct *p)
|
|
|
|
|
{
|
|
|
|
|
return rt_prio(p->prio);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_RT_MUTEXES
|
|
|
|
|
extern int rt_mutex_getprio(struct task_struct *p);
|
|
|
|
|
extern void rt_mutex_setprio(struct task_struct *p, int prio);
|
2015-05-05 11:49:49 -06:00
|
|
|
extern int rt_mutex_get_effective_prio(struct task_struct *task, int newprio);
|
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 06:43:44 -07:00
|
|
|
extern struct task_struct *rt_mutex_get_top_task(struct task_struct *task);
|
2013-02-07 08:47:07 -07:00
|
|
|
extern void rt_mutex_adjust_pi(struct task_struct *p);
|
|
|
|
|
static inline bool tsk_is_pi_blocked(struct task_struct *tsk)
|
|
|
|
|
{
|
|
|
|
|
return tsk->pi_blocked_on != NULL;
|
|
|
|
|
}
|
|
|
|
|
#else
|
|
|
|
|
static inline int rt_mutex_getprio(struct task_struct *p)
|
|
|
|
|
{
|
|
|
|
|
return p->normal_prio;
|
|
|
|
|
}
|
2014-02-07 12:58:42 -07:00
|
|
|
|
2015-05-05 11:49:49 -06:00
|
|
|
static inline int rt_mutex_get_effective_prio(struct task_struct *task,
|
|
|
|
|
int newprio)
|
2014-02-07 12:58:42 -07:00
|
|
|
{
|
2015-05-05 11:49:49 -06:00
|
|
|
return newprio;
|
2014-02-07 12:58:42 -07: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 06:43:44 -07:00
|
|
|
static inline struct task_struct *rt_mutex_get_top_task(struct task_struct *task)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2013-02-07 08:47:07 -07:00
|
|
|
# define rt_mutex_adjust_pi(p) do { } while (0)
|
|
|
|
|
static inline bool tsk_is_pi_blocked(struct task_struct *tsk)
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
extern void normalize_rt_tasks(void);
|
|
|
|
|
|
|
|
|
|
|
2013-02-22 10:20:11 -07:00
|
|
|
/*
|
|
|
|
|
* default timeslice is 100 msecs (used only for SCHED_RR tasks).
|
|
|
|
|
* Timeslices get refilled after they expire.
|
|
|
|
|
*/
|
|
|
|
|
#define RR_TIMESLICE (100 * HZ / 1000)
|
|
|
|
|
|
2013-02-07 08:47:07 -07:00
|
|
|
#endif /* _SCHED_RT_H */
|