2007-07-09 23:51:58 +07:00
|
|
|
/*
|
|
|
|
* Real-Time Scheduling Class (mapped to the SCHED_FIFO and SCHED_RR
|
|
|
|
* policies)
|
|
|
|
*/
|
|
|
|
|
2008-01-26 03:08:06 +07:00
|
|
|
#ifdef CONFIG_SMP
|
2008-01-26 03:08:15 +07:00
|
|
|
|
2008-01-26 03:08:18 +07:00
|
|
|
static inline int rt_overloaded(struct rq *rq)
|
2008-01-26 03:08:06 +07:00
|
|
|
{
|
2008-01-26 03:08:18 +07:00
|
|
|
return atomic_read(&rq->rd->rto_count);
|
2008-01-26 03:08:06 +07:00
|
|
|
}
|
2008-01-26 03:08:15 +07:00
|
|
|
|
2008-01-26 03:08:06 +07:00
|
|
|
static inline void rt_set_overload(struct rq *rq)
|
|
|
|
{
|
2008-06-05 02:04:05 +07:00
|
|
|
if (!rq->online)
|
|
|
|
return;
|
|
|
|
|
2008-11-24 23:05:05 +07:00
|
|
|
cpumask_set_cpu(rq->cpu, rq->rd->rto_mask);
|
2008-01-26 03:08:06 +07:00
|
|
|
/*
|
|
|
|
* Make sure the mask is visible before we set
|
|
|
|
* the overload count. That is checked to determine
|
|
|
|
* if we should look at the mask. It would be a shame
|
|
|
|
* if we looked at the mask, but the mask was not
|
|
|
|
* updated yet.
|
|
|
|
*/
|
|
|
|
wmb();
|
2008-01-26 03:08:18 +07:00
|
|
|
atomic_inc(&rq->rd->rto_count);
|
2008-01-26 03:08:06 +07:00
|
|
|
}
|
2008-01-26 03:08:15 +07:00
|
|
|
|
2008-01-26 03:08:06 +07:00
|
|
|
static inline void rt_clear_overload(struct rq *rq)
|
|
|
|
{
|
2008-06-05 02:04:05 +07:00
|
|
|
if (!rq->online)
|
|
|
|
return;
|
|
|
|
|
2008-01-26 03:08:06 +07:00
|
|
|
/* the order here really doesn't matter */
|
2008-01-26 03:08:18 +07:00
|
|
|
atomic_dec(&rq->rd->rto_count);
|
2008-11-24 23:05:05 +07:00
|
|
|
cpumask_clear_cpu(rq->cpu, rq->rd->rto_mask);
|
2008-01-26 03:08:06 +07:00
|
|
|
}
|
2008-01-26 03:08:07 +07:00
|
|
|
|
|
|
|
static void update_rt_migration(struct rq *rq)
|
|
|
|
{
|
2008-01-26 03:08:18 +07:00
|
|
|
if (rq->rt.rt_nr_migratory && (rq->rt.rt_nr_running > 1)) {
|
2008-01-26 03:08:23 +07:00
|
|
|
if (!rq->rt.overloaded) {
|
|
|
|
rt_set_overload(rq);
|
|
|
|
rq->rt.overloaded = 1;
|
|
|
|
}
|
|
|
|
} else if (rq->rt.overloaded) {
|
2008-01-26 03:08:07 +07:00
|
|
|
rt_clear_overload(rq);
|
2008-01-26 03:08:18 +07:00
|
|
|
rq->rt.overloaded = 0;
|
|
|
|
}
|
2008-01-26 03:08:07 +07:00
|
|
|
}
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
|
|
|
|
static void enqueue_pushable_task(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
|
|
|
plist_del(&p->pushable_tasks, &rq->rt.pushable_tasks);
|
|
|
|
plist_node_init(&p->pushable_tasks, p->prio);
|
|
|
|
plist_add(&p->pushable_tasks, &rq->rt.pushable_tasks);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dequeue_pushable_task(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
|
|
|
plist_del(&p->pushable_tasks, &rq->rt.pushable_tasks);
|
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
2009-01-14 20:55:39 +07:00
|
|
|
static inline
|
|
|
|
void enqueue_pushable_task(struct rq *rq, struct task_struct *p) {}
|
|
|
|
static inline
|
|
|
|
void dequeue_pushable_task(struct rq *rq, struct task_struct *p) {}
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
|
2008-01-26 03:08:06 +07:00
|
|
|
#endif /* CONFIG_SMP */
|
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
static inline struct task_struct *rt_task_of(struct sched_rt_entity *rt_se)
|
2008-01-26 03:08:29 +07:00
|
|
|
{
|
2008-01-26 03:08:30 +07:00
|
|
|
return container_of(rt_se, struct task_struct, rt);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int on_rt_rq(struct sched_rt_entity *rt_se)
|
|
|
|
{
|
|
|
|
return !list_empty(&rt_se->run_list);
|
|
|
|
}
|
|
|
|
|
2008-02-13 21:45:40 +07:00
|
|
|
#ifdef CONFIG_RT_GROUP_SCHED
|
2008-01-26 03:08:30 +07:00
|
|
|
|
2008-02-13 21:45:39 +07:00
|
|
|
static inline u64 sched_rt_runtime(struct rt_rq *rt_rq)
|
2008-01-26 03:08:30 +07:00
|
|
|
{
|
|
|
|
if (!rt_rq->tg)
|
2008-02-13 21:45:39 +07:00
|
|
|
return RUNTIME_INF;
|
2008-01-26 03:08:30 +07:00
|
|
|
|
2008-04-20 00:44:58 +07:00
|
|
|
return rt_rq->rt_runtime;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u64 sched_rt_period(struct rt_rq *rt_rq)
|
|
|
|
{
|
|
|
|
return ktime_to_ns(rt_rq->tg->rt_bandwidth.rt_period);
|
2008-01-26 03:08:30 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
#define for_each_leaf_rt_rq(rt_rq, rq) \
|
2008-12-15 13:26:48 +07:00
|
|
|
list_for_each_entry_rcu(rt_rq, &rq->leaf_rt_rq_list, leaf_rt_rq_list)
|
2008-01-26 03:08:30 +07:00
|
|
|
|
|
|
|
static inline struct rq *rq_of_rt_rq(struct rt_rq *rt_rq)
|
|
|
|
{
|
|
|
|
return rt_rq->rq;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct rt_rq *rt_rq_of_se(struct sched_rt_entity *rt_se)
|
|
|
|
{
|
|
|
|
return rt_se->rt_rq;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define for_each_sched_rt_entity(rt_se) \
|
|
|
|
for (; rt_se; rt_se = rt_se->parent)
|
|
|
|
|
|
|
|
static inline struct rt_rq *group_rt_rq(struct sched_rt_entity *rt_se)
|
|
|
|
{
|
|
|
|
return rt_se->my_q;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void enqueue_rt_entity(struct sched_rt_entity *rt_se);
|
|
|
|
static void dequeue_rt_entity(struct sched_rt_entity *rt_se);
|
|
|
|
|
2008-02-13 21:45:39 +07:00
|
|
|
static void sched_rt_rq_enqueue(struct rt_rq *rt_rq)
|
2008-01-26 03:08:30 +07:00
|
|
|
{
|
sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq
While working on the new version of the code for SCHED_SPORADIC I
noticed something strange in the present throttling mechanism. More
specifically in the throttling timer handler in sched_rt.c
(do_sched_rt_period_timer()) and in rt_rq_enqueue().
The problem is that, when unthrottling a runqueue, rt_rq_enqueue() only
asks for rescheduling if the runqueue has a sched_entity associated to
it (i.e., rt_rq->rt_se != NULL).
Now, if the runqueue is the root rq (which has a rt_se = NULL)
rescheduling does not take place, and it is delayed to some undefined
instant in the future.
This imply some random bandwidth usage by the RT tasks under throttling.
For instance, setting rt_runtime_us/rt_period_us = 950ms/1000ms an RT
task will get less than 95%. In our tests we got something varying
between 70% to 95%.
Using smaller time values, e.g., 95ms/100ms, things are even worse, and
I can see values also going down to 20-25%!!
The tests we performed are simply running 'yes' as a SCHED_FIFO task,
and checking the CPU usage with top, but we can investigate thoroughly
if you think it is needed.
Things go much better, for us, with the attached patch... Don't know if
it is the best approach, but it solved the issue for us.
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Michael Trimarchi <trimarchimichael@yahoo.it>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: <stable@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-03 22:40:46 +07:00
|
|
|
struct task_struct *curr = rq_of_rt_rq(rt_rq)->curr;
|
2008-01-26 03:08:30 +07:00
|
|
|
struct sched_rt_entity *rt_se = rt_rq->rt_se;
|
|
|
|
|
sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq
While working on the new version of the code for SCHED_SPORADIC I
noticed something strange in the present throttling mechanism. More
specifically in the throttling timer handler in sched_rt.c
(do_sched_rt_period_timer()) and in rt_rq_enqueue().
The problem is that, when unthrottling a runqueue, rt_rq_enqueue() only
asks for rescheduling if the runqueue has a sched_entity associated to
it (i.e., rt_rq->rt_se != NULL).
Now, if the runqueue is the root rq (which has a rt_se = NULL)
rescheduling does not take place, and it is delayed to some undefined
instant in the future.
This imply some random bandwidth usage by the RT tasks under throttling.
For instance, setting rt_runtime_us/rt_period_us = 950ms/1000ms an RT
task will get less than 95%. In our tests we got something varying
between 70% to 95%.
Using smaller time values, e.g., 95ms/100ms, things are even worse, and
I can see values also going down to 20-25%!!
The tests we performed are simply running 'yes' as a SCHED_FIFO task,
and checking the CPU usage with top, but we can investigate thoroughly
if you think it is needed.
Things go much better, for us, with the attached patch... Don't know if
it is the best approach, but it solved the issue for us.
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Michael Trimarchi <trimarchimichael@yahoo.it>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: <stable@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-03 22:40:46 +07:00
|
|
|
if (rt_rq->rt_nr_running) {
|
|
|
|
if (rt_se && !on_rt_rq(rt_se))
|
|
|
|
enqueue_rt_entity(rt_se);
|
2008-12-29 21:39:49 +07:00
|
|
|
if (rt_rq->highest_prio.curr < curr->prio)
|
2008-01-26 03:08:32 +07:00
|
|
|
resched_task(curr);
|
2008-01-26 03:08:30 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-02-13 21:45:39 +07:00
|
|
|
static void sched_rt_rq_dequeue(struct rt_rq *rt_rq)
|
2008-01-26 03:08:30 +07:00
|
|
|
{
|
|
|
|
struct sched_rt_entity *rt_se = rt_rq->rt_se;
|
|
|
|
|
|
|
|
if (rt_se && on_rt_rq(rt_se))
|
|
|
|
dequeue_rt_entity(rt_se);
|
|
|
|
}
|
|
|
|
|
2008-02-13 21:45:39 +07:00
|
|
|
static inline int rt_rq_throttled(struct rt_rq *rt_rq)
|
|
|
|
{
|
|
|
|
return rt_rq->rt_throttled && !rt_rq->rt_nr_boosted;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rt_se_boosted(struct sched_rt_entity *rt_se)
|
|
|
|
{
|
|
|
|
struct rt_rq *rt_rq = group_rt_rq(rt_se);
|
|
|
|
struct task_struct *p;
|
|
|
|
|
|
|
|
if (rt_rq)
|
|
|
|
return !!rt_rq->rt_nr_boosted;
|
|
|
|
|
|
|
|
p = rt_task_of(rt_se);
|
|
|
|
return p->prio != p->normal_prio;
|
|
|
|
}
|
|
|
|
|
2008-04-20 00:44:57 +07:00
|
|
|
#ifdef CONFIG_SMP
|
2008-11-24 23:05:05 +07:00
|
|
|
static inline const struct cpumask *sched_rt_period_mask(void)
|
2008-04-20 00:44:57 +07:00
|
|
|
{
|
|
|
|
return cpu_rq(smp_processor_id())->rd->span;
|
|
|
|
}
|
2008-01-26 03:08:30 +07:00
|
|
|
#else
|
2008-11-24 23:05:05 +07:00
|
|
|
static inline const struct cpumask *sched_rt_period_mask(void)
|
2008-04-20 00:44:57 +07:00
|
|
|
{
|
2008-11-24 23:05:05 +07:00
|
|
|
return cpu_online_mask;
|
2008-04-20 00:44:57 +07:00
|
|
|
}
|
|
|
|
#endif
|
2008-01-26 03:08:30 +07:00
|
|
|
|
2008-04-20 00:44:57 +07:00
|
|
|
static inline
|
|
|
|
struct rt_rq *sched_rt_period_rt_rq(struct rt_bandwidth *rt_b, int cpu)
|
2008-01-26 03:08:30 +07:00
|
|
|
{
|
2008-04-20 00:44:57 +07:00
|
|
|
return container_of(rt_b, struct task_group, rt_bandwidth)->rt_rq[cpu];
|
|
|
|
}
|
2008-02-13 21:45:39 +07:00
|
|
|
|
2008-04-20 00:44:58 +07:00
|
|
|
static inline struct rt_bandwidth *sched_rt_bandwidth(struct rt_rq *rt_rq)
|
|
|
|
{
|
|
|
|
return &rt_rq->tg->rt_bandwidth;
|
|
|
|
}
|
|
|
|
|
2008-06-25 01:09:43 +07:00
|
|
|
#else /* !CONFIG_RT_GROUP_SCHED */
|
2008-04-20 00:44:57 +07:00
|
|
|
|
|
|
|
static inline u64 sched_rt_runtime(struct rt_rq *rt_rq)
|
|
|
|
{
|
2008-04-20 00:44:58 +07:00
|
|
|
return rt_rq->rt_runtime;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u64 sched_rt_period(struct rt_rq *rt_rq)
|
|
|
|
{
|
|
|
|
return ktime_to_ns(def_rt_bandwidth.rt_period);
|
2008-01-26 03:08:30 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
#define for_each_leaf_rt_rq(rt_rq, rq) \
|
|
|
|
for (rt_rq = &rq->rt; rt_rq; rt_rq = NULL)
|
|
|
|
|
|
|
|
static inline struct rq *rq_of_rt_rq(struct rt_rq *rt_rq)
|
|
|
|
{
|
|
|
|
return container_of(rt_rq, struct rq, rt);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct rt_rq *rt_rq_of_se(struct sched_rt_entity *rt_se)
|
|
|
|
{
|
|
|
|
struct task_struct *p = rt_task_of(rt_se);
|
|
|
|
struct rq *rq = task_rq(p);
|
|
|
|
|
|
|
|
return &rq->rt;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define for_each_sched_rt_entity(rt_se) \
|
|
|
|
for (; rt_se; rt_se = NULL)
|
|
|
|
|
|
|
|
static inline struct rt_rq *group_rt_rq(struct sched_rt_entity *rt_se)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2008-02-13 21:45:39 +07:00
|
|
|
static inline void sched_rt_rq_enqueue(struct rt_rq *rt_rq)
|
2008-01-26 03:08:30 +07:00
|
|
|
{
|
2008-08-27 02:09:43 +07:00
|
|
|
if (rt_rq->rt_nr_running)
|
|
|
|
resched_task(rq_of_rt_rq(rt_rq)->curr);
|
2008-01-26 03:08:30 +07:00
|
|
|
}
|
|
|
|
|
2008-02-13 21:45:39 +07:00
|
|
|
static inline void sched_rt_rq_dequeue(struct rt_rq *rt_rq)
|
2008-01-26 03:08:30 +07:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2008-02-13 21:45:39 +07:00
|
|
|
static inline int rt_rq_throttled(struct rt_rq *rt_rq)
|
|
|
|
{
|
|
|
|
return rt_rq->rt_throttled;
|
|
|
|
}
|
2008-04-20 00:44:57 +07:00
|
|
|
|
2008-11-24 23:05:05 +07:00
|
|
|
static inline const struct cpumask *sched_rt_period_mask(void)
|
2008-04-20 00:44:57 +07:00
|
|
|
{
|
2008-11-24 23:05:05 +07:00
|
|
|
return cpu_online_mask;
|
2008-04-20 00:44:57 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline
|
|
|
|
struct rt_rq *sched_rt_period_rt_rq(struct rt_bandwidth *rt_b, int cpu)
|
|
|
|
{
|
|
|
|
return &cpu_rq(cpu)->rt;
|
|
|
|
}
|
|
|
|
|
2008-04-20 00:44:58 +07:00
|
|
|
static inline struct rt_bandwidth *sched_rt_bandwidth(struct rt_rq *rt_rq)
|
|
|
|
{
|
|
|
|
return &def_rt_bandwidth;
|
|
|
|
}
|
|
|
|
|
2008-06-25 01:09:43 +07:00
|
|
|
#endif /* CONFIG_RT_GROUP_SCHED */
|
2008-04-20 00:44:57 +07:00
|
|
|
|
2008-04-20 00:44:58 +07:00
|
|
|
#ifdef CONFIG_SMP
|
2008-09-23 20:33:43 +07:00
|
|
|
/*
|
|
|
|
* We ran out of runtime, see if we can borrow some from our neighbours.
|
|
|
|
*/
|
2008-06-19 19:22:25 +07:00
|
|
|
static int do_balance_runtime(struct rt_rq *rt_rq)
|
2008-04-20 00:44:58 +07:00
|
|
|
{
|
|
|
|
struct rt_bandwidth *rt_b = sched_rt_bandwidth(rt_rq);
|
|
|
|
struct root_domain *rd = cpu_rq(smp_processor_id())->rd;
|
|
|
|
int i, weight, more = 0;
|
|
|
|
u64 rt_period;
|
|
|
|
|
2008-11-24 23:05:05 +07:00
|
|
|
weight = cpumask_weight(rd->span);
|
2008-04-20 00:44:58 +07:00
|
|
|
|
|
|
|
spin_lock(&rt_b->rt_runtime_lock);
|
|
|
|
rt_period = ktime_to_ns(rt_b->rt_period);
|
2008-11-24 23:05:05 +07:00
|
|
|
for_each_cpu(i, rd->span) {
|
2008-04-20 00:44:58 +07:00
|
|
|
struct rt_rq *iter = sched_rt_period_rt_rq(rt_b, i);
|
|
|
|
s64 diff;
|
|
|
|
|
|
|
|
if (iter == rt_rq)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
spin_lock(&iter->rt_runtime_lock);
|
2008-09-23 20:33:43 +07:00
|
|
|
/*
|
|
|
|
* Either all rqs have inf runtime and there's nothing to steal
|
|
|
|
* or __disable_runtime() below sets a specific rq to inf to
|
|
|
|
* indicate its been disabled and disalow stealing.
|
|
|
|
*/
|
2008-06-05 19:49:58 +07:00
|
|
|
if (iter->rt_runtime == RUNTIME_INF)
|
|
|
|
goto next;
|
|
|
|
|
2008-09-23 20:33:43 +07:00
|
|
|
/*
|
|
|
|
* From runqueues with spare time, take 1/n part of their
|
|
|
|
* spare time, but no more than our period.
|
|
|
|
*/
|
2008-04-20 00:44:58 +07:00
|
|
|
diff = iter->rt_runtime - iter->rt_time;
|
|
|
|
if (diff > 0) {
|
2008-07-24 17:43:13 +07:00
|
|
|
diff = div_u64((u64)diff, weight);
|
2008-04-20 00:44:58 +07:00
|
|
|
if (rt_rq->rt_runtime + diff > rt_period)
|
|
|
|
diff = rt_period - rt_rq->rt_runtime;
|
|
|
|
iter->rt_runtime -= diff;
|
|
|
|
rt_rq->rt_runtime += diff;
|
|
|
|
more = 1;
|
|
|
|
if (rt_rq->rt_runtime == rt_period) {
|
|
|
|
spin_unlock(&iter->rt_runtime_lock);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2008-06-05 19:49:58 +07:00
|
|
|
next:
|
2008-04-20 00:44:58 +07:00
|
|
|
spin_unlock(&iter->rt_runtime_lock);
|
|
|
|
}
|
|
|
|
spin_unlock(&rt_b->rt_runtime_lock);
|
|
|
|
|
|
|
|
return more;
|
|
|
|
}
|
2008-06-05 19:49:58 +07:00
|
|
|
|
2008-09-23 20:33:43 +07:00
|
|
|
/*
|
|
|
|
* Ensure this RQ takes back all the runtime it lend to its neighbours.
|
|
|
|
*/
|
2008-06-05 19:49:58 +07:00
|
|
|
static void __disable_runtime(struct rq *rq)
|
|
|
|
{
|
|
|
|
struct root_domain *rd = rq->rd;
|
|
|
|
struct rt_rq *rt_rq;
|
|
|
|
|
|
|
|
if (unlikely(!scheduler_running))
|
|
|
|
return;
|
|
|
|
|
|
|
|
for_each_leaf_rt_rq(rt_rq, rq) {
|
|
|
|
struct rt_bandwidth *rt_b = sched_rt_bandwidth(rt_rq);
|
|
|
|
s64 want;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
spin_lock(&rt_b->rt_runtime_lock);
|
|
|
|
spin_lock(&rt_rq->rt_runtime_lock);
|
2008-09-23 20:33:43 +07:00
|
|
|
/*
|
|
|
|
* Either we're all inf and nobody needs to borrow, or we're
|
|
|
|
* already disabled and thus have nothing to do, or we have
|
|
|
|
* exactly the right amount of runtime to take out.
|
|
|
|
*/
|
2008-06-05 19:49:58 +07:00
|
|
|
if (rt_rq->rt_runtime == RUNTIME_INF ||
|
|
|
|
rt_rq->rt_runtime == rt_b->rt_runtime)
|
|
|
|
goto balanced;
|
|
|
|
spin_unlock(&rt_rq->rt_runtime_lock);
|
|
|
|
|
2008-09-23 20:33:43 +07:00
|
|
|
/*
|
|
|
|
* Calculate the difference between what we started out with
|
|
|
|
* and what we current have, that's the amount of runtime
|
|
|
|
* we lend and now have to reclaim.
|
|
|
|
*/
|
2008-06-05 19:49:58 +07:00
|
|
|
want = rt_b->rt_runtime - rt_rq->rt_runtime;
|
|
|
|
|
2008-09-23 20:33:43 +07:00
|
|
|
/*
|
|
|
|
* Greedy reclaim, take back as much as we can.
|
|
|
|
*/
|
2008-11-24 23:05:05 +07:00
|
|
|
for_each_cpu(i, rd->span) {
|
2008-06-05 19:49:58 +07:00
|
|
|
struct rt_rq *iter = sched_rt_period_rt_rq(rt_b, i);
|
|
|
|
s64 diff;
|
|
|
|
|
2008-09-23 20:33:43 +07:00
|
|
|
/*
|
|
|
|
* Can't reclaim from ourselves or disabled runqueues.
|
|
|
|
*/
|
2008-08-14 20:49:00 +07:00
|
|
|
if (iter == rt_rq || iter->rt_runtime == RUNTIME_INF)
|
2008-06-05 19:49:58 +07:00
|
|
|
continue;
|
|
|
|
|
|
|
|
spin_lock(&iter->rt_runtime_lock);
|
|
|
|
if (want > 0) {
|
|
|
|
diff = min_t(s64, iter->rt_runtime, want);
|
|
|
|
iter->rt_runtime -= diff;
|
|
|
|
want -= diff;
|
|
|
|
} else {
|
|
|
|
iter->rt_runtime -= want;
|
|
|
|
want -= want;
|
|
|
|
}
|
|
|
|
spin_unlock(&iter->rt_runtime_lock);
|
|
|
|
|
|
|
|
if (!want)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_lock(&rt_rq->rt_runtime_lock);
|
2008-09-23 20:33:43 +07:00
|
|
|
/*
|
|
|
|
* We cannot be left wanting - that would mean some runtime
|
|
|
|
* leaked out of the system.
|
|
|
|
*/
|
2008-06-05 19:49:58 +07:00
|
|
|
BUG_ON(want);
|
|
|
|
balanced:
|
2008-09-23 20:33:43 +07:00
|
|
|
/*
|
|
|
|
* Disable all the borrow logic by pretending we have inf
|
|
|
|
* runtime - in which case borrowing doesn't make sense.
|
|
|
|
*/
|
2008-06-05 19:49:58 +07:00
|
|
|
rt_rq->rt_runtime = RUNTIME_INF;
|
|
|
|
spin_unlock(&rt_rq->rt_runtime_lock);
|
|
|
|
spin_unlock(&rt_b->rt_runtime_lock);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void disable_runtime(struct rq *rq)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&rq->lock, flags);
|
|
|
|
__disable_runtime(rq);
|
|
|
|
spin_unlock_irqrestore(&rq->lock, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __enable_runtime(struct rq *rq)
|
|
|
|
{
|
|
|
|
struct rt_rq *rt_rq;
|
|
|
|
|
|
|
|
if (unlikely(!scheduler_running))
|
|
|
|
return;
|
|
|
|
|
2008-09-23 20:33:43 +07:00
|
|
|
/*
|
|
|
|
* Reset each runqueue's bandwidth settings
|
|
|
|
*/
|
2008-06-05 19:49:58 +07:00
|
|
|
for_each_leaf_rt_rq(rt_rq, rq) {
|
|
|
|
struct rt_bandwidth *rt_b = sched_rt_bandwidth(rt_rq);
|
|
|
|
|
|
|
|
spin_lock(&rt_b->rt_runtime_lock);
|
|
|
|
spin_lock(&rt_rq->rt_runtime_lock);
|
|
|
|
rt_rq->rt_runtime = rt_b->rt_runtime;
|
|
|
|
rt_rq->rt_time = 0;
|
2008-09-09 10:26:33 +07:00
|
|
|
rt_rq->rt_throttled = 0;
|
2008-06-05 19:49:58 +07:00
|
|
|
spin_unlock(&rt_rq->rt_runtime_lock);
|
|
|
|
spin_unlock(&rt_b->rt_runtime_lock);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void enable_runtime(struct rq *rq)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&rq->lock, flags);
|
|
|
|
__enable_runtime(rq);
|
|
|
|
spin_unlock_irqrestore(&rq->lock, flags);
|
|
|
|
}
|
|
|
|
|
2008-06-19 19:22:26 +07:00
|
|
|
static int balance_runtime(struct rt_rq *rt_rq)
|
|
|
|
{
|
|
|
|
int more = 0;
|
|
|
|
|
|
|
|
if (rt_rq->rt_time > rt_rq->rt_runtime) {
|
|
|
|
spin_unlock(&rt_rq->rt_runtime_lock);
|
|
|
|
more = do_balance_runtime(rt_rq);
|
|
|
|
spin_lock(&rt_rq->rt_runtime_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
return more;
|
|
|
|
}
|
2008-06-25 01:09:43 +07:00
|
|
|
#else /* !CONFIG_SMP */
|
2008-06-19 19:22:26 +07:00
|
|
|
static inline int balance_runtime(struct rt_rq *rt_rq)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2008-06-25 01:09:43 +07:00
|
|
|
#endif /* CONFIG_SMP */
|
2008-04-20 00:44:58 +07:00
|
|
|
|
2008-06-19 19:22:26 +07:00
|
|
|
static int do_sched_rt_period_timer(struct rt_bandwidth *rt_b, int overrun)
|
|
|
|
{
|
|
|
|
int i, idle = 1;
|
2008-11-24 23:05:05 +07:00
|
|
|
const struct cpumask *span;
|
2008-06-19 19:22:26 +07:00
|
|
|
|
2008-08-19 17:33:04 +07:00
|
|
|
if (!rt_bandwidth_enabled() || rt_b->rt_runtime == RUNTIME_INF)
|
2008-06-19 19:22:26 +07:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
span = sched_rt_period_mask();
|
2008-11-24 23:05:05 +07:00
|
|
|
for_each_cpu(i, span) {
|
2008-06-19 19:22:26 +07:00
|
|
|
int enqueue = 0;
|
|
|
|
struct rt_rq *rt_rq = sched_rt_period_rt_rq(rt_b, i);
|
|
|
|
struct rq *rq = rq_of_rt_rq(rt_rq);
|
|
|
|
|
|
|
|
spin_lock(&rq->lock);
|
|
|
|
if (rt_rq->rt_time) {
|
|
|
|
u64 runtime;
|
|
|
|
|
|
|
|
spin_lock(&rt_rq->rt_runtime_lock);
|
|
|
|
if (rt_rq->rt_throttled)
|
|
|
|
balance_runtime(rt_rq);
|
|
|
|
runtime = rt_rq->rt_runtime;
|
|
|
|
rt_rq->rt_time -= min(rt_rq->rt_time, overrun*runtime);
|
|
|
|
if (rt_rq->rt_throttled && rt_rq->rt_time < runtime) {
|
|
|
|
rt_rq->rt_throttled = 0;
|
|
|
|
enqueue = 1;
|
|
|
|
}
|
|
|
|
if (rt_rq->rt_time || rt_rq->rt_nr_running)
|
|
|
|
idle = 0;
|
|
|
|
spin_unlock(&rt_rq->rt_runtime_lock);
|
2008-06-19 19:22:28 +07:00
|
|
|
} else if (rt_rq->rt_nr_running)
|
|
|
|
idle = 0;
|
2008-06-19 19:22:26 +07:00
|
|
|
|
|
|
|
if (enqueue)
|
|
|
|
sched_rt_rq_enqueue(rt_rq);
|
|
|
|
spin_unlock(&rq->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
return idle;
|
|
|
|
}
|
2008-04-20 00:44:58 +07:00
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
static inline int rt_se_prio(struct sched_rt_entity *rt_se)
|
|
|
|
{
|
2008-02-13 21:45:40 +07:00
|
|
|
#ifdef CONFIG_RT_GROUP_SCHED
|
2008-01-26 03:08:30 +07:00
|
|
|
struct rt_rq *rt_rq = group_rt_rq(rt_se);
|
|
|
|
|
|
|
|
if (rt_rq)
|
2008-12-29 21:39:49 +07:00
|
|
|
return rt_rq->highest_prio.curr;
|
2008-01-26 03:08:30 +07:00
|
|
|
#endif
|
|
|
|
|
|
|
|
return rt_task_of(rt_se)->prio;
|
|
|
|
}
|
|
|
|
|
2008-02-13 21:45:39 +07:00
|
|
|
static int sched_rt_runtime_exceeded(struct rt_rq *rt_rq)
|
2008-01-26 03:08:30 +07:00
|
|
|
{
|
2008-02-13 21:45:39 +07:00
|
|
|
u64 runtime = sched_rt_runtime(rt_rq);
|
2008-01-26 03:08:29 +07:00
|
|
|
|
|
|
|
if (rt_rq->rt_throttled)
|
2008-02-13 21:45:39 +07:00
|
|
|
return rt_rq_throttled(rt_rq);
|
2008-01-26 03:08:29 +07:00
|
|
|
|
2008-04-20 00:44:58 +07:00
|
|
|
if (sched_rt_runtime(rt_rq) >= sched_rt_period(rt_rq))
|
|
|
|
return 0;
|
|
|
|
|
2008-06-19 19:22:25 +07:00
|
|
|
balance_runtime(rt_rq);
|
|
|
|
runtime = sched_rt_runtime(rt_rq);
|
|
|
|
if (runtime == RUNTIME_INF)
|
|
|
|
return 0;
|
2008-04-20 00:44:58 +07:00
|
|
|
|
2008-02-13 21:45:39 +07:00
|
|
|
if (rt_rq->rt_time > runtime) {
|
2008-01-26 03:08:30 +07:00
|
|
|
rt_rq->rt_throttled = 1;
|
2008-02-13 21:45:39 +07:00
|
|
|
if (rt_rq_throttled(rt_rq)) {
|
2008-02-13 21:45:39 +07:00
|
|
|
sched_rt_rq_dequeue(rt_rq);
|
2008-02-13 21:45:39 +07:00
|
|
|
return 1;
|
|
|
|
}
|
2008-01-26 03:08:29 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-07-09 23:51:58 +07:00
|
|
|
/*
|
|
|
|
* Update the current task's runtime statistics. Skip current tasks that
|
|
|
|
* are not in our scheduling class.
|
|
|
|
*/
|
2007-10-15 22:00:13 +07:00
|
|
|
static void update_curr_rt(struct rq *rq)
|
2007-07-09 23:51:58 +07:00
|
|
|
{
|
|
|
|
struct task_struct *curr = rq->curr;
|
2008-01-26 03:08:30 +07:00
|
|
|
struct sched_rt_entity *rt_se = &curr->rt;
|
|
|
|
struct rt_rq *rt_rq = rt_rq_of_se(rt_se);
|
2007-07-09 23:51:58 +07:00
|
|
|
u64 delta_exec;
|
|
|
|
|
|
|
|
if (!task_has_rt_policy(curr))
|
|
|
|
return;
|
|
|
|
|
2007-08-09 16:16:47 +07:00
|
|
|
delta_exec = rq->clock - curr->se.exec_start;
|
2007-07-09 23:51:58 +07:00
|
|
|
if (unlikely((s64)delta_exec < 0))
|
|
|
|
delta_exec = 0;
|
2007-08-02 22:41:40 +07:00
|
|
|
|
|
|
|
schedstat_set(curr->se.exec_max, max(curr->se.exec_max, delta_exec));
|
2007-07-09 23:51:58 +07:00
|
|
|
|
|
|
|
curr->se.sum_exec_runtime += delta_exec;
|
timers: fix itimer/many thread hang
Overview
This patch reworks the handling of POSIX CPU timers, including the
ITIMER_PROF, ITIMER_VIRT timers and rlimit handling. It was put together
with the help of Roland McGrath, the owner and original writer of this code.
The problem we ran into, and the reason for this rework, has to do with using
a profiling timer in a process with a large number of threads. It appears
that the performance of the old implementation of run_posix_cpu_timers() was
at least O(n*3) (where "n" is the number of threads in a process) or worse.
Everything is fine with an increasing number of threads until the time taken
for that routine to run becomes the same as or greater than the tick time, at
which point things degrade rather quickly.
This patch fixes bug 9906, "Weird hang with NPTL and SIGPROF."
Code Changes
This rework corrects the implementation of run_posix_cpu_timers() to make it
run in constant time for a particular machine. (Performance may vary between
one machine and another depending upon whether the kernel is built as single-
or multiprocessor and, in the latter case, depending upon the number of
running processors.) To do this, at each tick we now update fields in
signal_struct as well as task_struct. The run_posix_cpu_timers() function
uses those fields to make its decisions.
We define a new structure, "task_cputime," to contain user, system and
scheduler times and use these in appropriate places:
struct task_cputime {
cputime_t utime;
cputime_t stime;
unsigned long long sum_exec_runtime;
};
This is included in the structure "thread_group_cputime," which is a new
substructure of signal_struct and which varies for uniprocessor versus
multiprocessor kernels. For uniprocessor kernels, it uses "task_cputime" as
a simple substructure, while for multiprocessor kernels it is a pointer:
struct thread_group_cputime {
struct task_cputime totals;
};
struct thread_group_cputime {
struct task_cputime *totals;
};
We also add a new task_cputime substructure directly to signal_struct, to
cache the earliest expiration of process-wide timers, and task_cputime also
replaces the it_*_expires fields of task_struct (used for earliest expiration
of thread timers). The "thread_group_cputime" structure contains process-wide
timers that are updated via account_user_time() and friends. In the non-SMP
case the structure is a simple aggregator; unfortunately in the SMP case that
simplicity was not achievable due to cache-line contention between CPUs (in
one measured case performance was actually _worse_ on a 16-cpu system than
the same test on a 4-cpu system, due to this contention). For SMP, the
thread_group_cputime counters are maintained as a per-cpu structure allocated
using alloc_percpu(). The timer functions update only the timer field in
the structure corresponding to the running CPU, obtained using per_cpu_ptr().
We define a set of inline functions in sched.h that we use to maintain the
thread_group_cputime structure and hide the differences between UP and SMP
implementations from the rest of the kernel. The thread_group_cputime_init()
function initializes the thread_group_cputime structure for the given task.
The thread_group_cputime_alloc() is a no-op for UP; for SMP it calls the
out-of-line function thread_group_cputime_alloc_smp() to allocate and fill
in the per-cpu structures and fields. The thread_group_cputime_free()
function, also a no-op for UP, in SMP frees the per-cpu structures. The
thread_group_cputime_clone_thread() function (also a UP no-op) for SMP calls
thread_group_cputime_alloc() if the per-cpu structures haven't yet been
allocated. The thread_group_cputime() function fills the task_cputime
structure it is passed with the contents of the thread_group_cputime fields;
in UP it's that simple but in SMP it must also safely check that tsk->signal
is non-NULL (if it is it just uses the appropriate fields of task_struct) and,
if so, sums the per-cpu values for each online CPU. Finally, the three
functions account_group_user_time(), account_group_system_time() and
account_group_exec_runtime() are used by timer functions to update the
respective fields of the thread_group_cputime structure.
Non-SMP operation is trivial and will not be mentioned further.
The per-cpu structure is always allocated when a task creates its first new
thread, via a call to thread_group_cputime_clone_thread() from copy_signal().
It is freed at process exit via a call to thread_group_cputime_free() from
cleanup_signal().
All functions that formerly summed utime/stime/sum_sched_runtime values from
from all threads in the thread group now use thread_group_cputime() to
snapshot the values in the thread_group_cputime structure or the values in
the task structure itself if the per-cpu structure hasn't been allocated.
Finally, the code in kernel/posix-cpu-timers.c has changed quite a bit.
The run_posix_cpu_timers() function has been split into a fast path and a
slow path; the former safely checks whether there are any expired thread
timers and, if not, just returns, while the slow path does the heavy lifting.
With the dedicated thread group fields, timers are no longer "rebalanced" and
the process_timer_rebalance() function and related code has gone away. All
summing loops are gone and all code that used them now uses the
thread_group_cputime() inline. When process-wide timers are set, the new
task_cputime structure in signal_struct is used to cache the earliest
expiration; this is checked in the fast path.
Performance
The fix appears not to add significant overhead to existing operations. It
generally performs the same as the current code except in two cases, one in
which it performs slightly worse (Case 5 below) and one in which it performs
very significantly better (Case 2 below). Overall it's a wash except in those
two cases.
I've since done somewhat more involved testing on a dual-core Opteron system.
Case 1: With no itimer running, for a test with 100,000 threads, the fixed
kernel took 1428.5 seconds, 513 seconds more than the unfixed system,
all of which was spent in the system. There were twice as many
voluntary context switches with the fix as without it.
Case 2: With an itimer running at .01 second ticks and 4000 threads (the most
an unmodified kernel can handle), the fixed kernel ran the test in
eight percent of the time (5.8 seconds as opposed to 70 seconds) and
had better tick accuracy (.012 seconds per tick as opposed to .023
seconds per tick).
Case 3: A 4000-thread test with an initial timer tick of .01 second and an
interval of 10,000 seconds (i.e. a timer that ticks only once) had
very nearly the same performance in both cases: 6.3 seconds elapsed
for the fixed kernel versus 5.5 seconds for the unfixed kernel.
With fewer threads (eight in these tests), the Case 1 test ran in essentially
the same time on both the modified and unmodified kernels (5.2 seconds versus
5.8 seconds). The Case 2 test ran in about the same time as well, 5.9 seconds
versus 5.4 seconds but again with much better tick accuracy, .013 seconds per
tick versus .025 seconds per tick for the unmodified kernel.
Since the fix affected the rlimit code, I also tested soft and hard CPU limits.
Case 4: With a hard CPU limit of 20 seconds and eight threads (and an itimer
running), the modified kernel was very slightly favored in that while
it killed the process in 19.997 seconds of CPU time (5.002 seconds of
wall time), only .003 seconds of that was system time, the rest was
user time. The unmodified kernel killed the process in 20.001 seconds
of CPU (5.014 seconds of wall time) of which .016 seconds was system
time. Really, though, the results were too close to call. The results
were essentially the same with no itimer running.
Case 5: With a soft limit of 20 seconds and a hard limit of 2000 seconds
(where the hard limit would never be reached) and an itimer running,
the modified kernel exhibited worse tick accuracy than the unmodified
kernel: .050 seconds/tick versus .028 seconds/tick. Otherwise,
performance was almost indistinguishable. With no itimer running this
test exhibited virtually identical behavior and times in both cases.
In times past I did some limited performance testing. those results are below.
On a four-cpu Opteron system without this fix, a sixteen-thread test executed
in 3569.991 seconds, of which user was 3568.435s and system was 1.556s. On
the same system with the fix, user and elapsed time were about the same, but
system time dropped to 0.007 seconds. Performance with eight, four and one
thread were comparable. Interestingly, the timer ticks with the fix seemed
more accurate: The sixteen-thread test with the fix received 149543 ticks
for 0.024 seconds per tick, while the same test without the fix received 58720
for 0.061 seconds per tick. Both cases were configured for an interval of
0.01 seconds. Again, the other tests were comparable. Each thread in this
test computed the primes up to 25,000,000.
I also did a test with a large number of threads, 100,000 threads, which is
impossible without the fix. In this case each thread computed the primes only
up to 10,000 (to make the runtime manageable). System time dominated, at
1546.968 seconds out of a total 2176.906 seconds (giving a user time of
629.938s). It received 147651 ticks for 0.015 seconds per tick, still quite
accurate. There is obviously no comparable test without the fix.
Signed-off-by: Frank Mayhar <fmayhar@google.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-09-12 23:54:39 +07:00
|
|
|
account_group_exec_runtime(curr, delta_exec);
|
|
|
|
|
2007-08-09 16:16:47 +07:00
|
|
|
curr->se.exec_start = rq->clock;
|
2007-12-03 02:04:49 +07:00
|
|
|
cpuacct_charge(curr, delta_exec);
|
2008-01-26 03:08:29 +07:00
|
|
|
|
2008-08-19 17:33:04 +07:00
|
|
|
if (!rt_bandwidth_enabled())
|
|
|
|
return;
|
|
|
|
|
2008-04-20 00:44:59 +07:00
|
|
|
for_each_sched_rt_entity(rt_se) {
|
|
|
|
rt_rq = rt_rq_of_se(rt_se);
|
|
|
|
|
2008-08-19 17:33:03 +07:00
|
|
|
if (sched_rt_runtime(rt_rq) != RUNTIME_INF) {
|
2008-10-31 20:03:41 +07:00
|
|
|
spin_lock(&rt_rq->rt_runtime_lock);
|
2008-08-19 17:33:03 +07:00
|
|
|
rt_rq->rt_time += delta_exec;
|
|
|
|
if (sched_rt_runtime_exceeded(rt_rq))
|
|
|
|
resched_task(curr);
|
2008-10-31 20:03:41 +07:00
|
|
|
spin_unlock(&rt_rq->rt_runtime_lock);
|
2008-08-19 17:33:03 +07:00
|
|
|
}
|
2008-04-20 00:44:59 +07:00
|
|
|
}
|
2007-07-09 23:51:58 +07:00
|
|
|
}
|
|
|
|
|
2008-12-29 21:39:49 +07:00
|
|
|
#if defined CONFIG_SMP || defined CONFIG_RT_GROUP_SCHED
|
|
|
|
|
|
|
|
static struct task_struct *pick_next_highest_task_rt(struct rq *rq, int cpu);
|
|
|
|
|
|
|
|
static inline int next_prio(struct rq *rq)
|
|
|
|
{
|
|
|
|
struct task_struct *next = pick_next_highest_task_rt(rq, rq->cpu);
|
|
|
|
|
|
|
|
if (next && rt_prio(next->prio))
|
|
|
|
return next->prio;
|
|
|
|
else
|
|
|
|
return MAX_RT_PRIO;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
static inline
|
|
|
|
void inc_rt_tasks(struct sched_rt_entity *rt_se, struct rt_rq *rt_rq)
|
2008-01-26 03:08:03 +07:00
|
|
|
{
|
2008-12-29 21:39:49 +07:00
|
|
|
int prio = rt_se_prio(rt_se);
|
2008-07-11 19:34:54 +07:00
|
|
|
#ifdef CONFIG_SMP
|
2008-12-29 21:39:49 +07:00
|
|
|
struct rq *rq = rq_of_rt_rq(rt_rq);
|
2008-07-11 19:34:54 +07:00
|
|
|
#endif
|
2008-06-05 02:04:05 +07:00
|
|
|
|
2008-12-29 21:39:49 +07:00
|
|
|
WARN_ON(!rt_prio(prio));
|
|
|
|
rt_rq->rt_nr_running++;
|
|
|
|
#if defined CONFIG_SMP || defined CONFIG_RT_GROUP_SCHED
|
2008-12-29 21:39:49 +07:00
|
|
|
if (prio < rt_rq->highest_prio.curr) {
|
2008-12-29 21:39:49 +07:00
|
|
|
|
2008-12-29 21:39:49 +07:00
|
|
|
/*
|
|
|
|
* If the new task is higher in priority than anything on the
|
|
|
|
* run-queue, we have a new high that must be published to
|
|
|
|
* the world. We also know that the previous high becomes
|
|
|
|
* our next-highest.
|
|
|
|
*/
|
|
|
|
rt_rq->highest_prio.next = rt_rq->highest_prio.curr;
|
|
|
|
rt_rq->highest_prio.curr = prio;
|
2008-06-05 17:25:37 +07:00
|
|
|
#ifdef CONFIG_SMP
|
2008-06-05 02:04:05 +07:00
|
|
|
if (rq->online)
|
2008-12-29 21:39:49 +07:00
|
|
|
cpupri_set(&rq->rd->cpupri, rq->cpu, prio);
|
2008-06-05 17:25:37 +07:00
|
|
|
#endif
|
2008-12-29 21:39:49 +07:00
|
|
|
} else if (prio == rt_rq->highest_prio.curr)
|
|
|
|
/*
|
|
|
|
* If the next task is equal in priority to the highest on
|
|
|
|
* the run-queue, then we implicitly know that the next highest
|
|
|
|
* task cannot be any lower than current
|
|
|
|
*/
|
|
|
|
rt_rq->highest_prio.next = prio;
|
|
|
|
else if (prio < rt_rq->highest_prio.next)
|
|
|
|
/*
|
|
|
|
* Otherwise, we need to recompute next-highest
|
|
|
|
*/
|
|
|
|
rt_rq->highest_prio.next = next_prio(rq);
|
2008-01-26 03:08:30 +07:00
|
|
|
#endif
|
2008-01-26 03:08:04 +07:00
|
|
|
#ifdef CONFIG_SMP
|
2008-12-29 21:39:49 +07:00
|
|
|
if (rt_se->nr_cpus_allowed > 1)
|
2008-01-26 03:08:07 +07:00
|
|
|
rq->rt.rt_nr_migratory++;
|
|
|
|
|
2008-12-29 21:39:49 +07:00
|
|
|
update_rt_migration(rq);
|
2008-01-26 03:08:30 +07:00
|
|
|
#endif
|
2008-02-13 21:45:40 +07:00
|
|
|
#ifdef CONFIG_RT_GROUP_SCHED
|
2008-02-13 21:45:39 +07:00
|
|
|
if (rt_se_boosted(rt_se))
|
|
|
|
rt_rq->rt_nr_boosted++;
|
2008-04-20 00:44:57 +07:00
|
|
|
|
|
|
|
if (rt_rq->tg)
|
|
|
|
start_rt_bandwidth(&rt_rq->tg->rt_bandwidth);
|
|
|
|
#else
|
|
|
|
start_rt_bandwidth(&def_rt_bandwidth);
|
2008-02-13 21:45:39 +07:00
|
|
|
#endif
|
2008-01-26 03:08:03 +07:00
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
static inline
|
|
|
|
void dec_rt_tasks(struct sched_rt_entity *rt_se, struct rt_rq *rt_rq)
|
2008-01-26 03:08:03 +07:00
|
|
|
{
|
2008-05-13 02:21:01 +07:00
|
|
|
#ifdef CONFIG_SMP
|
2008-12-29 21:39:49 +07:00
|
|
|
struct rq *rq = rq_of_rt_rq(rt_rq);
|
2008-12-29 21:39:49 +07:00
|
|
|
int highest_prio = rt_rq->highest_prio.curr;
|
2008-05-13 02:21:01 +07:00
|
|
|
#endif
|
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
WARN_ON(!rt_prio(rt_se_prio(rt_se)));
|
|
|
|
WARN_ON(!rt_rq->rt_nr_running);
|
|
|
|
rt_rq->rt_nr_running--;
|
2008-02-13 21:45:40 +07:00
|
|
|
#if defined CONFIG_SMP || defined CONFIG_RT_GROUP_SCHED
|
2008-01-26 03:08:30 +07:00
|
|
|
if (rt_rq->rt_nr_running) {
|
2008-12-29 21:39:49 +07:00
|
|
|
int prio = rt_se_prio(rt_se);
|
2008-01-26 03:08:04 +07:00
|
|
|
|
2008-12-29 21:39:49 +07:00
|
|
|
WARN_ON(prio < rt_rq->highest_prio.curr);
|
2008-01-26 03:08:04 +07:00
|
|
|
|
2008-12-29 21:39:49 +07:00
|
|
|
/*
|
|
|
|
* This may have been our highest or next-highest priority
|
|
|
|
* task and therefore we may have some recomputation to do
|
|
|
|
*/
|
|
|
|
if (prio == rt_rq->highest_prio.curr) {
|
|
|
|
struct rt_prio_array *array = &rt_rq->active;
|
|
|
|
|
|
|
|
rt_rq->highest_prio.curr =
|
2008-01-26 03:08:04 +07:00
|
|
|
sched_find_first_bit(array->bitmap);
|
2008-12-29 21:39:49 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (prio <= rt_rq->highest_prio.next)
|
|
|
|
rt_rq->highest_prio.next = next_prio(rq);
|
2008-01-26 03:08:04 +07:00
|
|
|
} else
|
2008-12-29 21:39:49 +07:00
|
|
|
rt_rq->highest_prio.curr = MAX_RT_PRIO;
|
2008-01-26 03:08:30 +07:00
|
|
|
#endif
|
|
|
|
#ifdef CONFIG_SMP
|
2008-12-29 21:39:49 +07:00
|
|
|
if (rt_se->nr_cpus_allowed > 1)
|
2008-01-26 03:08:07 +07:00
|
|
|
rq->rt.rt_nr_migratory--;
|
|
|
|
|
2008-12-29 21:39:49 +07:00
|
|
|
if (rq->online && rt_rq->highest_prio.curr != highest_prio)
|
|
|
|
cpupri_set(&rq->rd->cpupri, rq->cpu, rt_rq->highest_prio.curr);
|
2008-06-05 02:04:05 +07:00
|
|
|
|
2008-12-29 21:39:49 +07:00
|
|
|
update_rt_migration(rq);
|
2008-01-26 03:08:04 +07:00
|
|
|
#endif /* CONFIG_SMP */
|
2008-02-13 21:45:40 +07:00
|
|
|
#ifdef CONFIG_RT_GROUP_SCHED
|
2008-02-13 21:45:39 +07:00
|
|
|
if (rt_se_boosted(rt_se))
|
|
|
|
rt_rq->rt_nr_boosted--;
|
|
|
|
|
|
|
|
WARN_ON(!rt_rq->rt_nr_running && rt_rq->rt_nr_boosted);
|
|
|
|
#endif
|
2008-01-26 03:08:03 +07:00
|
|
|
}
|
|
|
|
|
2008-06-19 14:06:57 +07:00
|
|
|
static void __enqueue_rt_entity(struct sched_rt_entity *rt_se)
|
2007-07-09 23:51:58 +07:00
|
|
|
{
|
2008-01-26 03:08:30 +07:00
|
|
|
struct rt_rq *rt_rq = rt_rq_of_se(rt_se);
|
|
|
|
struct rt_prio_array *array = &rt_rq->active;
|
|
|
|
struct rt_rq *group_rq = group_rt_rq(rt_se);
|
sched: rework of "prioritize non-migratable tasks over migratable ones"
regarding this commit: 45c01e824991b2dd0a332e19efc4901acb31209f
I think we can do it simpler. Please take a look at the patch below.
Instead of having 2 separate arrays (which is + ~800 bytes on x86_32 and
twice so on x86_64), let's add "exclusive" (the ones that are bound to
this CPU) tasks to the head of the queue and "shared" ones -- to the
end.
In case of a few newly woken up "exclusive" tasks, they are 'stacked'
(not queued as now), meaning that a task {i+1} is being placed in front
of the previously woken up task {i}. But I don't think that this
behavior may cause any realistic problems.
There are a couple of changes on top of this one.
(1) in check_preempt_curr_rt()
I don't think there is a need for the "pick_next_rt_entity(rq, &rq->rt)
!= &rq->curr->rt" check.
enqueue_task_rt(p) and check_preempt_curr_rt() are always called one
after another with rq->lock being held so the following check
"p->rt.nr_cpus_allowed == 1 && rq->curr->rt.nr_cpus_allowed != 1" should
be enough (well, just its left part) to guarantee that 'p' has been
queued in front of the 'curr'.
(2) in set_cpus_allowed_rt()
I don't thinks there is a need for requeue_task_rt() here.
Perhaps, the only case when 'requeue' (+ reschedule) might be useful is
as follows:
i) weight == 1 && cpu_isset(task_cpu(p), *new_mask)
i.e. a task is being bound to this CPU);
ii) 'p' != rq->curr
but here, 'p' has already been on this CPU for a while and was not
migrated. i.e. it's possible that 'rq->curr' would not have high chances
to be migrated right at this particular moment (although, has chance in
a bit longer term), should we allow it to be preempted.
Anyway, I think we should not perhaps make it more complex trying to
address some rare corner cases. For instance, that's why a single queue
approach would be preferable. Unless I'm missing something obvious, this
approach gives us similar functionality at lower cost.
Verified only compilation-wise.
(Almost)-Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-11 05:58:30 +07:00
|
|
|
struct list_head *queue = array->queue + rt_se_prio(rt_se);
|
2007-07-09 23:51:58 +07:00
|
|
|
|
2008-06-19 14:06:57 +07:00
|
|
|
/*
|
|
|
|
* Don't enqueue the group if its throttled, or when empty.
|
|
|
|
* The latter is a consequence of the former when a child group
|
|
|
|
* get throttled and the current group doesn't have any other
|
|
|
|
* active members.
|
|
|
|
*/
|
|
|
|
if (group_rq && (rt_rq_throttled(group_rq) || !group_rq->rt_nr_running))
|
2008-01-26 03:08:30 +07:00
|
|
|
return;
|
2008-01-26 03:08:03 +07:00
|
|
|
|
2008-07-02 04:32:15 +07:00
|
|
|
list_add_tail(&rt_se->run_list, queue);
|
2008-01-26 03:08:30 +07:00
|
|
|
__set_bit(rt_se_prio(rt_se), array->bitmap);
|
2008-01-26 03:08:27 +07:00
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
inc_rt_tasks(rt_se, rt_rq);
|
|
|
|
}
|
|
|
|
|
2008-06-19 14:06:57 +07:00
|
|
|
static void __dequeue_rt_entity(struct sched_rt_entity *rt_se)
|
2008-01-26 03:08:30 +07:00
|
|
|
{
|
|
|
|
struct rt_rq *rt_rq = rt_rq_of_se(rt_se);
|
|
|
|
struct rt_prio_array *array = &rt_rq->active;
|
|
|
|
|
|
|
|
list_del_init(&rt_se->run_list);
|
|
|
|
if (list_empty(array->queue + rt_se_prio(rt_se)))
|
|
|
|
__clear_bit(rt_se_prio(rt_se), array->bitmap);
|
|
|
|
|
|
|
|
dec_rt_tasks(rt_se, rt_rq);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Because the prio of an upper entry depends on the lower
|
|
|
|
* entries, we must remove entries top - down.
|
|
|
|
*/
|
2008-06-19 14:06:57 +07:00
|
|
|
static void dequeue_rt_stack(struct sched_rt_entity *rt_se)
|
2008-01-26 03:08:30 +07:00
|
|
|
{
|
2008-06-19 14:06:57 +07:00
|
|
|
struct sched_rt_entity *back = NULL;
|
2008-01-26 03:08:30 +07:00
|
|
|
|
2008-04-20 00:45:00 +07:00
|
|
|
for_each_sched_rt_entity(rt_se) {
|
|
|
|
rt_se->back = back;
|
|
|
|
back = rt_se;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (rt_se = back; rt_se; rt_se = rt_se->back) {
|
|
|
|
if (on_rt_rq(rt_se))
|
2008-06-19 14:06:57 +07:00
|
|
|
__dequeue_rt_entity(rt_se);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void enqueue_rt_entity(struct sched_rt_entity *rt_se)
|
|
|
|
{
|
|
|
|
dequeue_rt_stack(rt_se);
|
|
|
|
for_each_sched_rt_entity(rt_se)
|
|
|
|
__enqueue_rt_entity(rt_se);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dequeue_rt_entity(struct sched_rt_entity *rt_se)
|
|
|
|
{
|
|
|
|
dequeue_rt_stack(rt_se);
|
|
|
|
|
|
|
|
for_each_sched_rt_entity(rt_se) {
|
|
|
|
struct rt_rq *rt_rq = group_rt_rq(rt_se);
|
|
|
|
|
|
|
|
if (rt_rq && rt_rq->rt_nr_running)
|
|
|
|
__enqueue_rt_entity(rt_se);
|
2008-04-20 00:45:00 +07:00
|
|
|
}
|
2007-07-09 23:51:58 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Adding/removing a task to/from a priority array:
|
|
|
|
*/
|
2008-01-26 03:08:30 +07:00
|
|
|
static void enqueue_task_rt(struct rq *rq, struct task_struct *p, int wakeup)
|
|
|
|
{
|
|
|
|
struct sched_rt_entity *rt_se = &p->rt;
|
|
|
|
|
|
|
|
if (wakeup)
|
|
|
|
rt_se->timeout = 0;
|
|
|
|
|
2008-06-19 14:06:57 +07:00
|
|
|
enqueue_rt_entity(rt_se);
|
2008-06-27 18:41:14 +07:00
|
|
|
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
if (!task_current(rq, p) && p->rt.nr_cpus_allowed > 1)
|
|
|
|
enqueue_pushable_task(rq, p);
|
|
|
|
|
2008-06-27 18:41:14 +07:00
|
|
|
inc_cpu_load(rq, p->se.load.weight);
|
2008-01-26 03:08:30 +07:00
|
|
|
}
|
|
|
|
|
2007-08-09 16:16:48 +07:00
|
|
|
static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int sleep)
|
2007-07-09 23:51:58 +07:00
|
|
|
{
|
2008-01-26 03:08:30 +07:00
|
|
|
struct sched_rt_entity *rt_se = &p->rt;
|
2007-07-09 23:51:58 +07:00
|
|
|
|
2007-08-09 16:16:48 +07:00
|
|
|
update_curr_rt(rq);
|
2008-06-19 14:06:57 +07:00
|
|
|
dequeue_rt_entity(rt_se);
|
2008-06-27 18:41:14 +07:00
|
|
|
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
dequeue_pushable_task(rq, p);
|
|
|
|
|
2008-06-27 18:41:14 +07:00
|
|
|
dec_cpu_load(rq, p->se.load.weight);
|
2007-07-09 23:51:58 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Put task to the end of the run list without the overhead of dequeue
|
|
|
|
* followed by enqueue.
|
|
|
|
*/
|
2008-07-02 04:32:15 +07:00
|
|
|
static void
|
|
|
|
requeue_rt_entity(struct rt_rq *rt_rq, struct sched_rt_entity *rt_se, int head)
|
2008-01-26 03:08:30 +07:00
|
|
|
{
|
2008-06-19 14:09:15 +07:00
|
|
|
if (on_rt_rq(rt_se)) {
|
2008-07-02 04:32:15 +07:00
|
|
|
struct rt_prio_array *array = &rt_rq->active;
|
|
|
|
struct list_head *queue = array->queue + rt_se_prio(rt_se);
|
|
|
|
|
|
|
|
if (head)
|
|
|
|
list_move(&rt_se->run_list, queue);
|
|
|
|
else
|
|
|
|
list_move_tail(&rt_se->run_list, queue);
|
2008-06-19 14:09:15 +07:00
|
|
|
}
|
2008-01-26 03:08:30 +07:00
|
|
|
}
|
|
|
|
|
2008-07-02 04:32:15 +07:00
|
|
|
static void requeue_task_rt(struct rq *rq, struct task_struct *p, int head)
|
2007-07-09 23:51:58 +07:00
|
|
|
{
|
2008-01-26 03:08:30 +07:00
|
|
|
struct sched_rt_entity *rt_se = &p->rt;
|
|
|
|
struct rt_rq *rt_rq;
|
2007-07-09 23:51:58 +07:00
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
for_each_sched_rt_entity(rt_se) {
|
|
|
|
rt_rq = rt_rq_of_se(rt_se);
|
2008-07-02 04:32:15 +07:00
|
|
|
requeue_rt_entity(rt_rq, rt_se, head);
|
2008-01-26 03:08:30 +07:00
|
|
|
}
|
2007-07-09 23:51:58 +07:00
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
static void yield_task_rt(struct rq *rq)
|
2007-07-09 23:51:58 +07:00
|
|
|
{
|
2008-07-02 04:32:15 +07:00
|
|
|
requeue_task_rt(rq, rq->curr, 0);
|
2007-07-09 23:51:58 +07:00
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:09 +07:00
|
|
|
#ifdef CONFIG_SMP
|
2008-01-26 03:08:10 +07:00
|
|
|
static int find_lowest_rq(struct task_struct *task);
|
|
|
|
|
2008-01-26 03:08:09 +07:00
|
|
|
static int select_task_rq_rt(struct task_struct *p, int sync)
|
|
|
|
{
|
2008-01-26 03:08:10 +07:00
|
|
|
struct rq *rq = task_rq(p);
|
|
|
|
|
|
|
|
/*
|
2008-01-26 03:08:12 +07:00
|
|
|
* If the current task is an RT task, then
|
|
|
|
* try to see if we can wake this RT task up on another
|
|
|
|
* runqueue. Otherwise simply start this RT task
|
|
|
|
* on its current runqueue.
|
|
|
|
*
|
|
|
|
* We want to avoid overloading runqueues. Even if
|
|
|
|
* the RT task is of higher priority than the current RT task.
|
|
|
|
* RT tasks behave differently than other tasks. If
|
|
|
|
* one gets preempted, we try to push it off to another queue.
|
|
|
|
* So trying to keep a preempting RT task on the same
|
|
|
|
* cache hot CPU will force the running RT task to
|
|
|
|
* a cold CPU. So we waste all the cache for the lower
|
|
|
|
* RT task in hopes of saving some of a RT task
|
|
|
|
* that is just being woken and probably will have
|
|
|
|
* cold cache anyway.
|
2008-01-26 03:08:10 +07:00
|
|
|
*/
|
2008-01-26 03:08:13 +07:00
|
|
|
if (unlikely(rt_task(rq->curr)) &&
|
2008-01-26 03:08:30 +07:00
|
|
|
(p->rt.nr_cpus_allowed > 1)) {
|
2008-01-26 03:08:10 +07:00
|
|
|
int cpu = find_lowest_rq(p);
|
|
|
|
|
|
|
|
return (cpu == -1) ? task_cpu(p) : cpu;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Otherwise, just let it ride on the affined RQ and the
|
|
|
|
* post-schedule router will push the preempted task away
|
|
|
|
*/
|
2008-01-26 03:08:09 +07:00
|
|
|
return task_cpu(p);
|
|
|
|
}
|
2008-07-02 04:32:15 +07:00
|
|
|
|
|
|
|
static void check_preempt_equal_prio(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
2008-11-24 23:05:13 +07:00
|
|
|
cpumask_var_t mask;
|
2008-07-02 04:32:15 +07:00
|
|
|
|
|
|
|
if (rq->curr->rt.nr_cpus_allowed == 1)
|
|
|
|
return;
|
|
|
|
|
2008-11-24 23:05:13 +07:00
|
|
|
if (!alloc_cpumask_var(&mask, GFP_ATOMIC))
|
2008-07-02 04:32:15 +07:00
|
|
|
return;
|
|
|
|
|
2008-11-24 23:05:13 +07:00
|
|
|
if (p->rt.nr_cpus_allowed != 1
|
|
|
|
&& cpupri_find(&rq->rd->cpupri, p, mask))
|
|
|
|
goto free;
|
|
|
|
|
|
|
|
if (!cpupri_find(&rq->rd->cpupri, rq->curr, mask))
|
|
|
|
goto free;
|
2008-07-02 04:32:15 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* There appears to be other cpus that can accept
|
|
|
|
* current and none to run 'p', so lets reschedule
|
|
|
|
* to try and push current away:
|
|
|
|
*/
|
|
|
|
requeue_task_rt(rq, p, 1);
|
|
|
|
resched_task(rq->curr);
|
2008-11-24 23:05:13 +07:00
|
|
|
free:
|
|
|
|
free_cpumask_var(mask);
|
2008-07-02 04:32:15 +07:00
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:09 +07:00
|
|
|
#endif /* CONFIG_SMP */
|
|
|
|
|
2007-07-09 23:51:58 +07:00
|
|
|
/*
|
|
|
|
* Preempt the current task with a newly woken task if needed:
|
|
|
|
*/
|
2008-09-21 04:38:02 +07:00
|
|
|
static void check_preempt_curr_rt(struct rq *rq, struct task_struct *p, int sync)
|
2007-07-09 23:51:58 +07:00
|
|
|
{
|
sched: prioritize non-migratable tasks over migratable ones
Dmitry Adamushko pointed out a known flaw in the rt-balancing algorithm
that could allow suboptimal balancing if a non-migratable task gets
queued behind a running migratable one. It is discussed in this thread:
http://lkml.org/lkml/2008/4/22/296
This issue has been further exacerbated by a recent checkin to
sched-devel (git-id 5eee63a5ebc19a870ac40055c0be49457f3a89a3).
>From a pure priority standpoint, the run-queue is doing the "right"
thing. Using Dmitry's nomenclature, if T0 is on cpu1 first, and T1
wakes up at equal or lower priority (affined only to cpu1) later, it
*should* wait for T0 to finish. However, in reality that is likely
suboptimal from a system perspective if there are other cores that
could allow T0 and T1 to run concurrently. Since T1 can not migrate,
the only choice for higher concurrency is to try to move T0. This is
not something we addessed in the recent rt-balancing re-work.
This patch tries to enhance the balancing algorithm by accomodating this
scenario. It accomplishes this by incorporating the migratability of a
task into its priority calculation. Within a numerical tsk->prio, a
non-migratable task is logically higher than a migratable one. We
maintain this by introducing a new per-priority queue (xqueue, or
exclusive-queue) for holding non-migratable tasks. The scheduler will
draw from the xqueue over the standard shared-queue (squeue) when
available.
There are several details for utilizing this properly.
1) During task-wake-up, we not only need to check if the priority
preempts the current task, but we also need to check for this
non-migratable condition. Therefore, if a non-migratable task wakes
up and sees an equal priority migratable task already running, it
will attempt to preempt it *if* there is a likelyhood that the
current task will find an immediate home.
2) Tasks only get this non-migratable "priority boost" on wake-up. Any
requeuing will result in the non-migratable task being queued to the
end of the shared queue. This is an attempt to prevent the system
from being completely unfair to migratable tasks during things like
SCHED_RR timeslicing.
I am sure this patch introduces potentially "odd" behavior if you
concoct a scenario where a bunch of non-migratable threads could starve
migratable ones given the right pattern. I am not yet convinced that
this is a problem since we are talking about tasks of equal RT priority
anyway, and there never is much in the way of guarantees against
starvation under that scenario anyway. (e.g. you could come up with a
similar scenario with a specific timing environment verses an affinity
environment). I can be convinced otherwise, but for now I think this is
"ok".
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
CC: Dmitry Adamushko <dmitry.adamushko@gmail.com>
CC: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-13 02:20:41 +07:00
|
|
|
if (p->prio < rq->curr->prio) {
|
2007-07-09 23:51:58 +07:00
|
|
|
resched_task(rq->curr);
|
sched: prioritize non-migratable tasks over migratable ones
Dmitry Adamushko pointed out a known flaw in the rt-balancing algorithm
that could allow suboptimal balancing if a non-migratable task gets
queued behind a running migratable one. It is discussed in this thread:
http://lkml.org/lkml/2008/4/22/296
This issue has been further exacerbated by a recent checkin to
sched-devel (git-id 5eee63a5ebc19a870ac40055c0be49457f3a89a3).
>From a pure priority standpoint, the run-queue is doing the "right"
thing. Using Dmitry's nomenclature, if T0 is on cpu1 first, and T1
wakes up at equal or lower priority (affined only to cpu1) later, it
*should* wait for T0 to finish. However, in reality that is likely
suboptimal from a system perspective if there are other cores that
could allow T0 and T1 to run concurrently. Since T1 can not migrate,
the only choice for higher concurrency is to try to move T0. This is
not something we addessed in the recent rt-balancing re-work.
This patch tries to enhance the balancing algorithm by accomodating this
scenario. It accomplishes this by incorporating the migratability of a
task into its priority calculation. Within a numerical tsk->prio, a
non-migratable task is logically higher than a migratable one. We
maintain this by introducing a new per-priority queue (xqueue, or
exclusive-queue) for holding non-migratable tasks. The scheduler will
draw from the xqueue over the standard shared-queue (squeue) when
available.
There are several details for utilizing this properly.
1) During task-wake-up, we not only need to check if the priority
preempts the current task, but we also need to check for this
non-migratable condition. Therefore, if a non-migratable task wakes
up and sees an equal priority migratable task already running, it
will attempt to preempt it *if* there is a likelyhood that the
current task will find an immediate home.
2) Tasks only get this non-migratable "priority boost" on wake-up. Any
requeuing will result in the non-migratable task being queued to the
end of the shared queue. This is an attempt to prevent the system
from being completely unfair to migratable tasks during things like
SCHED_RR timeslicing.
I am sure this patch introduces potentially "odd" behavior if you
concoct a scenario where a bunch of non-migratable threads could starve
migratable ones given the right pattern. I am not yet convinced that
this is a problem since we are talking about tasks of equal RT priority
anyway, and there never is much in the way of guarantees against
starvation under that scenario anyway. (e.g. you could come up with a
similar scenario with a specific timing environment verses an affinity
environment). I can be convinced otherwise, but for now I think this is
"ok".
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
CC: Dmitry Adamushko <dmitry.adamushko@gmail.com>
CC: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-13 02:20:41 +07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
/*
|
|
|
|
* If:
|
|
|
|
*
|
|
|
|
* - the newly woken task is of equal priority to the current task
|
|
|
|
* - the newly woken task is non-migratable while current is migratable
|
|
|
|
* - current will be preempted on the next reschedule
|
|
|
|
*
|
|
|
|
* we should check to see if current can readily move to a different
|
|
|
|
* cpu. If so, we will reschedule to allow the push logic to try
|
|
|
|
* to move current somewhere else, making room for our non-migratable
|
|
|
|
* task.
|
|
|
|
*/
|
2008-07-02 04:32:15 +07:00
|
|
|
if (p->prio == rq->curr->prio && !need_resched())
|
|
|
|
check_preempt_equal_prio(rq, p);
|
sched: prioritize non-migratable tasks over migratable ones
Dmitry Adamushko pointed out a known flaw in the rt-balancing algorithm
that could allow suboptimal balancing if a non-migratable task gets
queued behind a running migratable one. It is discussed in this thread:
http://lkml.org/lkml/2008/4/22/296
This issue has been further exacerbated by a recent checkin to
sched-devel (git-id 5eee63a5ebc19a870ac40055c0be49457f3a89a3).
>From a pure priority standpoint, the run-queue is doing the "right"
thing. Using Dmitry's nomenclature, if T0 is on cpu1 first, and T1
wakes up at equal or lower priority (affined only to cpu1) later, it
*should* wait for T0 to finish. However, in reality that is likely
suboptimal from a system perspective if there are other cores that
could allow T0 and T1 to run concurrently. Since T1 can not migrate,
the only choice for higher concurrency is to try to move T0. This is
not something we addessed in the recent rt-balancing re-work.
This patch tries to enhance the balancing algorithm by accomodating this
scenario. It accomplishes this by incorporating the migratability of a
task into its priority calculation. Within a numerical tsk->prio, a
non-migratable task is logically higher than a migratable one. We
maintain this by introducing a new per-priority queue (xqueue, or
exclusive-queue) for holding non-migratable tasks. The scheduler will
draw from the xqueue over the standard shared-queue (squeue) when
available.
There are several details for utilizing this properly.
1) During task-wake-up, we not only need to check if the priority
preempts the current task, but we also need to check for this
non-migratable condition. Therefore, if a non-migratable task wakes
up and sees an equal priority migratable task already running, it
will attempt to preempt it *if* there is a likelyhood that the
current task will find an immediate home.
2) Tasks only get this non-migratable "priority boost" on wake-up. Any
requeuing will result in the non-migratable task being queued to the
end of the shared queue. This is an attempt to prevent the system
from being completely unfair to migratable tasks during things like
SCHED_RR timeslicing.
I am sure this patch introduces potentially "odd" behavior if you
concoct a scenario where a bunch of non-migratable threads could starve
migratable ones given the right pattern. I am not yet convinced that
this is a problem since we are talking about tasks of equal RT priority
anyway, and there never is much in the way of guarantees against
starvation under that scenario anyway. (e.g. you could come up with a
similar scenario with a specific timing environment verses an affinity
environment). I can be convinced otherwise, but for now I think this is
"ok".
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
CC: Dmitry Adamushko <dmitry.adamushko@gmail.com>
CC: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-13 02:20:41 +07:00
|
|
|
#endif
|
2007-07-09 23:51:58 +07:00
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
static struct sched_rt_entity *pick_next_rt_entity(struct rq *rq,
|
|
|
|
struct rt_rq *rt_rq)
|
2007-07-09 23:51:58 +07:00
|
|
|
{
|
2008-01-26 03:08:30 +07:00
|
|
|
struct rt_prio_array *array = &rt_rq->active;
|
|
|
|
struct sched_rt_entity *next = NULL;
|
2007-07-09 23:51:58 +07:00
|
|
|
struct list_head *queue;
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
idx = sched_find_first_bit(array->bitmap);
|
2008-01-26 03:08:30 +07:00
|
|
|
BUG_ON(idx >= MAX_RT_PRIO);
|
2007-07-09 23:51:58 +07:00
|
|
|
|
|
|
|
queue = array->queue + idx;
|
2008-01-26 03:08:30 +07:00
|
|
|
next = list_entry(queue->next, struct sched_rt_entity, run_list);
|
2008-01-26 03:08:34 +07:00
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
return next;
|
|
|
|
}
|
2007-07-09 23:51:58 +07:00
|
|
|
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
static struct task_struct *_pick_next_task_rt(struct rq *rq)
|
2008-01-26 03:08:30 +07:00
|
|
|
{
|
|
|
|
struct sched_rt_entity *rt_se;
|
|
|
|
struct task_struct *p;
|
|
|
|
struct rt_rq *rt_rq;
|
2007-07-09 23:51:58 +07:00
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
rt_rq = &rq->rt;
|
|
|
|
|
|
|
|
if (unlikely(!rt_rq->rt_nr_running))
|
|
|
|
return NULL;
|
|
|
|
|
2008-02-13 21:45:39 +07:00
|
|
|
if (rt_rq_throttled(rt_rq))
|
2008-01-26 03:08:30 +07:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
do {
|
|
|
|
rt_se = pick_next_rt_entity(rq, rt_rq);
|
2008-01-26 03:08:34 +07:00
|
|
|
BUG_ON(!rt_se);
|
2008-01-26 03:08:30 +07:00
|
|
|
rt_rq = group_rt_rq(rt_se);
|
|
|
|
} while (rt_rq);
|
|
|
|
|
|
|
|
p = rt_task_of(rt_se);
|
|
|
|
p->se.exec_start = rq->clock;
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct task_struct *pick_next_task_rt(struct rq *rq)
|
|
|
|
{
|
|
|
|
struct task_struct *p = _pick_next_task_rt(rq);
|
|
|
|
|
|
|
|
/* The running task is never eligible for pushing */
|
|
|
|
if (p)
|
|
|
|
dequeue_pushable_task(rq, p);
|
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
return p;
|
2007-07-09 23:51:58 +07:00
|
|
|
}
|
|
|
|
|
2007-08-09 16:16:49 +07:00
|
|
|
static void put_prev_task_rt(struct rq *rq, struct task_struct *p)
|
2007-07-09 23:51:58 +07:00
|
|
|
{
|
2007-08-09 16:16:48 +07:00
|
|
|
update_curr_rt(rq);
|
2007-07-09 23:51:58 +07:00
|
|
|
p->se.exec_start = 0;
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The previous task needs to be made eligible for pushing
|
|
|
|
* if it is still active
|
|
|
|
*/
|
|
|
|
if (p->se.on_rq && p->rt.nr_cpus_allowed > 1)
|
|
|
|
enqueue_pushable_task(rq, p);
|
2007-07-09 23:51:58 +07:00
|
|
|
}
|
|
|
|
|
2007-10-24 23:23:51 +07:00
|
|
|
#ifdef CONFIG_SMP
|
2008-01-26 03:08:30 +07:00
|
|
|
|
2008-01-26 03:08:05 +07:00
|
|
|
/* Only try algorithms three times */
|
|
|
|
#define RT_MAX_TRIES 3
|
|
|
|
|
|
|
|
static void deactivate_task(struct rq *rq, struct task_struct *p, int sleep);
|
|
|
|
|
2008-01-26 03:08:07 +07:00
|
|
|
static int pick_rt_task(struct rq *rq, struct task_struct *p, int cpu)
|
|
|
|
{
|
|
|
|
if (!task_running(rq, p) &&
|
2008-11-24 23:05:14 +07:00
|
|
|
(cpu < 0 || cpumask_test_cpu(cpu, &p->cpus_allowed)) &&
|
2008-01-26 03:08:30 +07:00
|
|
|
(p->rt.nr_cpus_allowed > 1))
|
2008-01-26 03:08:07 +07:00
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:05 +07:00
|
|
|
/* Return the second highest RT task, NULL otherwise */
|
2008-01-26 03:08:14 +07:00
|
|
|
static struct task_struct *pick_next_highest_task_rt(struct rq *rq, int cpu)
|
2008-01-26 03:08:05 +07:00
|
|
|
{
|
2008-01-26 03:08:30 +07:00
|
|
|
struct task_struct *next = NULL;
|
|
|
|
struct sched_rt_entity *rt_se;
|
|
|
|
struct rt_prio_array *array;
|
|
|
|
struct rt_rq *rt_rq;
|
2008-01-26 03:08:05 +07:00
|
|
|
int idx;
|
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
for_each_leaf_rt_rq(rt_rq, rq) {
|
|
|
|
array = &rt_rq->active;
|
|
|
|
idx = sched_find_first_bit(array->bitmap);
|
|
|
|
next_idx:
|
|
|
|
if (idx >= MAX_RT_PRIO)
|
|
|
|
continue;
|
|
|
|
if (next && next->prio < idx)
|
|
|
|
continue;
|
|
|
|
list_for_each_entry(rt_se, array->queue + idx, run_list) {
|
|
|
|
struct task_struct *p = rt_task_of(rt_se);
|
|
|
|
if (pick_rt_task(rq, p, cpu)) {
|
|
|
|
next = p;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!next) {
|
|
|
|
idx = find_next_bit(array->bitmap, MAX_RT_PRIO, idx+1);
|
|
|
|
goto next_idx;
|
|
|
|
}
|
2008-01-26 03:08:07 +07:00
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:05 +07:00
|
|
|
return next;
|
|
|
|
}
|
|
|
|
|
2008-11-24 23:05:13 +07:00
|
|
|
static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask);
|
2008-01-26 03:08:05 +07:00
|
|
|
|
2008-01-26 03:08:11 +07:00
|
|
|
static inline int pick_optimal_cpu(int this_cpu, cpumask_t *mask)
|
|
|
|
{
|
|
|
|
int first;
|
|
|
|
|
|
|
|
/* "this_cpu" is cheaper to preempt than a remote processor */
|
|
|
|
if ((this_cpu != -1) && cpu_isset(this_cpu, *mask))
|
|
|
|
return this_cpu;
|
|
|
|
|
|
|
|
first = first_cpu(*mask);
|
|
|
|
if (first != NR_CPUS)
|
|
|
|
return first;
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int find_lowest_rq(struct task_struct *task)
|
|
|
|
{
|
|
|
|
struct sched_domain *sd;
|
2008-11-24 23:05:14 +07:00
|
|
|
struct cpumask *lowest_mask = __get_cpu_var(local_cpu_mask);
|
2008-01-26 03:08:11 +07:00
|
|
|
int this_cpu = smp_processor_id();
|
|
|
|
int cpu = task_cpu(task);
|
2008-01-26 03:08:13 +07:00
|
|
|
|
2008-05-13 02:21:01 +07:00
|
|
|
if (task->rt.nr_cpus_allowed == 1)
|
|
|
|
return -1; /* No other targets possible */
|
2008-01-26 03:08:11 +07:00
|
|
|
|
2008-05-13 02:21:01 +07:00
|
|
|
if (!cpupri_find(&task_rq(task)->rd->cpupri, task, lowest_mask))
|
|
|
|
return -1; /* No targets found */
|
2008-01-26 03:08:11 +07:00
|
|
|
|
2008-07-15 18:43:49 +07:00
|
|
|
/*
|
|
|
|
* Only consider CPUs that are usable for migration.
|
|
|
|
* I guess we might want to change cpupri_find() to ignore those
|
|
|
|
* in the first place.
|
|
|
|
*/
|
2008-11-24 23:05:14 +07:00
|
|
|
cpumask_and(lowest_mask, lowest_mask, cpu_active_mask);
|
2008-07-15 18:43:49 +07:00
|
|
|
|
2008-01-26 03:08:11 +07:00
|
|
|
/*
|
|
|
|
* At this point we have built a mask of cpus representing the
|
|
|
|
* lowest priority tasks in the system. Now we want to elect
|
|
|
|
* the best one based on our affinity and topology.
|
|
|
|
*
|
|
|
|
* We prioritize the last cpu that the task executed on since
|
|
|
|
* it is most likely cache-hot in that location.
|
|
|
|
*/
|
2008-11-24 23:05:14 +07:00
|
|
|
if (cpumask_test_cpu(cpu, lowest_mask))
|
2008-01-26 03:08:11 +07:00
|
|
|
return cpu;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Otherwise, we consult the sched_domains span maps to figure
|
|
|
|
* out which cpu is logically closest to our hot cache data.
|
|
|
|
*/
|
|
|
|
if (this_cpu == cpu)
|
|
|
|
this_cpu = -1; /* Skip this_cpu opt if the same */
|
|
|
|
|
|
|
|
for_each_domain(cpu, sd) {
|
|
|
|
if (sd->flags & SD_WAKE_AFFINE) {
|
|
|
|
cpumask_t domain_mask;
|
|
|
|
int best_cpu;
|
|
|
|
|
2008-11-24 23:05:04 +07:00
|
|
|
cpumask_and(&domain_mask, sched_domain_span(sd),
|
|
|
|
lowest_mask);
|
2008-01-26 03:08:11 +07:00
|
|
|
|
|
|
|
best_cpu = pick_optimal_cpu(this_cpu,
|
|
|
|
&domain_mask);
|
|
|
|
if (best_cpu != -1)
|
|
|
|
return best_cpu;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* And finally, if there were no matches within the domains
|
|
|
|
* just give the caller *something* to work with from the compatible
|
|
|
|
* locations.
|
|
|
|
*/
|
|
|
|
return pick_optimal_cpu(this_cpu, lowest_mask);
|
2008-01-26 03:08:10 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Will lock the rq it finds */
|
2008-01-26 03:08:15 +07:00
|
|
|
static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq)
|
2008-01-26 03:08:10 +07:00
|
|
|
{
|
|
|
|
struct rq *lowest_rq = NULL;
|
|
|
|
int tries;
|
2008-01-26 03:08:15 +07:00
|
|
|
int cpu;
|
2008-01-26 03:08:05 +07:00
|
|
|
|
2008-01-26 03:08:10 +07:00
|
|
|
for (tries = 0; tries < RT_MAX_TRIES; tries++) {
|
|
|
|
cpu = find_lowest_rq(task);
|
|
|
|
|
2008-01-26 03:08:10 +07:00
|
|
|
if ((cpu == -1) || (cpu == rq->cpu))
|
2008-01-26 03:08:05 +07:00
|
|
|
break;
|
|
|
|
|
2008-01-26 03:08:10 +07:00
|
|
|
lowest_rq = cpu_rq(cpu);
|
|
|
|
|
2008-01-26 03:08:05 +07:00
|
|
|
/* if the prio of this runqueue changed, try again */
|
2008-01-26 03:08:10 +07:00
|
|
|
if (double_lock_balance(rq, lowest_rq)) {
|
2008-01-26 03:08:05 +07:00
|
|
|
/*
|
|
|
|
* We had to unlock the run queue. In
|
|
|
|
* the mean time, task could have
|
|
|
|
* migrated already or had its affinity changed.
|
|
|
|
* Also make sure that it wasn't scheduled on its rq.
|
|
|
|
*/
|
2008-01-26 03:08:10 +07:00
|
|
|
if (unlikely(task_rq(task) != rq ||
|
2008-11-24 23:05:14 +07:00
|
|
|
!cpumask_test_cpu(lowest_rq->cpu,
|
|
|
|
&task->cpus_allowed) ||
|
2008-01-26 03:08:10 +07:00
|
|
|
task_running(rq, task) ||
|
2008-01-26 03:08:05 +07:00
|
|
|
!task->se.on_rq)) {
|
2008-01-26 03:08:15 +07:00
|
|
|
|
2008-01-26 03:08:05 +07:00
|
|
|
spin_unlock(&lowest_rq->lock);
|
|
|
|
lowest_rq = NULL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If this rq is still suitable use it. */
|
2008-12-29 21:39:49 +07:00
|
|
|
if (lowest_rq->rt.highest_prio.curr > task->prio)
|
2008-01-26 03:08:05 +07:00
|
|
|
break;
|
|
|
|
|
|
|
|
/* try again */
|
2008-08-11 14:30:22 +07:00
|
|
|
double_unlock_balance(rq, lowest_rq);
|
2008-01-26 03:08:05 +07:00
|
|
|
lowest_rq = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return lowest_rq;
|
|
|
|
}
|
|
|
|
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
static inline int has_pushable_tasks(struct rq *rq)
|
|
|
|
{
|
|
|
|
return !plist_head_empty(&rq->rt.pushable_tasks);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct task_struct *pick_next_pushable_task(struct rq *rq)
|
|
|
|
{
|
|
|
|
struct task_struct *p;
|
|
|
|
|
|
|
|
if (!has_pushable_tasks(rq))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
p = plist_first_entry(&rq->rt.pushable_tasks,
|
|
|
|
struct task_struct, pushable_tasks);
|
|
|
|
|
|
|
|
BUG_ON(rq->cpu != task_cpu(p));
|
|
|
|
BUG_ON(task_current(rq, p));
|
|
|
|
BUG_ON(p->rt.nr_cpus_allowed <= 1);
|
|
|
|
|
|
|
|
BUG_ON(!p->se.on_rq);
|
|
|
|
BUG_ON(!rt_task(p));
|
|
|
|
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:05 +07:00
|
|
|
/*
|
|
|
|
* If the current CPU has more than one RT task, see if the non
|
|
|
|
* running task can migrate over to a CPU that is running a task
|
|
|
|
* of lesser priority.
|
|
|
|
*/
|
2008-01-26 03:08:09 +07:00
|
|
|
static int push_rt_task(struct rq *rq)
|
2008-01-26 03:08:05 +07:00
|
|
|
{
|
|
|
|
struct task_struct *next_task;
|
|
|
|
struct rq *lowest_rq;
|
|
|
|
|
2008-01-26 03:08:12 +07:00
|
|
|
if (!rq->rt.overloaded)
|
|
|
|
return 0;
|
|
|
|
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
next_task = pick_next_pushable_task(rq);
|
2008-01-26 03:08:05 +07:00
|
|
|
if (!next_task)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
retry:
|
2008-01-26 03:08:09 +07:00
|
|
|
if (unlikely(next_task == rq->curr)) {
|
2008-01-26 03:08:07 +07:00
|
|
|
WARN_ON(1);
|
2008-01-26 03:08:05 +07:00
|
|
|
return 0;
|
2008-01-26 03:08:07 +07:00
|
|
|
}
|
2008-01-26 03:08:05 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* It's possible that the next_task slipped in of
|
|
|
|
* higher priority than current. If that's the case
|
|
|
|
* just reschedule current.
|
|
|
|
*/
|
2008-01-26 03:08:09 +07:00
|
|
|
if (unlikely(next_task->prio < rq->curr->prio)) {
|
|
|
|
resched_task(rq->curr);
|
2008-01-26 03:08:05 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:09 +07:00
|
|
|
/* We might release rq lock */
|
2008-01-26 03:08:05 +07:00
|
|
|
get_task_struct(next_task);
|
|
|
|
|
|
|
|
/* find_lock_lowest_rq locks the rq if found */
|
2008-01-26 03:08:09 +07:00
|
|
|
lowest_rq = find_lock_lowest_rq(next_task, rq);
|
2008-01-26 03:08:05 +07:00
|
|
|
if (!lowest_rq) {
|
|
|
|
struct task_struct *task;
|
|
|
|
/*
|
2008-01-26 03:08:09 +07:00
|
|
|
* find lock_lowest_rq releases rq->lock
|
2008-12-29 21:39:53 +07:00
|
|
|
* so it is possible that next_task has migrated.
|
|
|
|
*
|
|
|
|
* We need to make sure that the task is still on the same
|
|
|
|
* run-queue and is also still the next task eligible for
|
|
|
|
* pushing.
|
2008-01-26 03:08:05 +07:00
|
|
|
*/
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
task = pick_next_pushable_task(rq);
|
2008-12-29 21:39:53 +07:00
|
|
|
if (task_cpu(next_task) == rq->cpu && task == next_task) {
|
|
|
|
/*
|
|
|
|
* If we get here, the task hasnt moved at all, but
|
|
|
|
* it has failed to push. We will not try again,
|
|
|
|
* since the other cpus will pull from us when they
|
|
|
|
* are ready.
|
|
|
|
*/
|
|
|
|
dequeue_pushable_task(rq, next_task);
|
|
|
|
goto out;
|
2008-01-26 03:08:05 +07:00
|
|
|
}
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
|
2008-12-29 21:39:53 +07:00
|
|
|
if (!task)
|
|
|
|
/* No more tasks, just exit */
|
|
|
|
goto out;
|
|
|
|
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
/*
|
2008-12-29 21:39:53 +07:00
|
|
|
* Something has shifted, try again.
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
*/
|
2008-12-29 21:39:53 +07:00
|
|
|
put_task_struct(next_task);
|
|
|
|
next_task = task;
|
|
|
|
goto retry;
|
2008-01-26 03:08:05 +07:00
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:09 +07:00
|
|
|
deactivate_task(rq, next_task, 0);
|
2008-01-26 03:08:05 +07:00
|
|
|
set_task_cpu(next_task, lowest_rq->cpu);
|
|
|
|
activate_task(lowest_rq, next_task, 0);
|
|
|
|
|
|
|
|
resched_task(lowest_rq->curr);
|
|
|
|
|
2008-08-11 14:30:22 +07:00
|
|
|
double_unlock_balance(rq, lowest_rq);
|
2008-01-26 03:08:05 +07:00
|
|
|
|
|
|
|
out:
|
|
|
|
put_task_struct(next_task);
|
|
|
|
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
return 1;
|
2008-01-26 03:08:05 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void push_rt_tasks(struct rq *rq)
|
|
|
|
{
|
|
|
|
/* push_rt_task will return true if it moved an RT */
|
|
|
|
while (push_rt_task(rq))
|
|
|
|
;
|
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:07 +07:00
|
|
|
static int pull_rt_task(struct rq *this_rq)
|
|
|
|
{
|
2008-01-26 03:08:17 +07:00
|
|
|
int this_cpu = this_rq->cpu, ret = 0, cpu;
|
2008-12-29 21:39:49 +07:00
|
|
|
struct task_struct *p;
|
2008-01-26 03:08:07 +07:00
|
|
|
struct rq *src_rq;
|
|
|
|
|
2008-01-26 03:08:18 +07:00
|
|
|
if (likely(!rt_overloaded(this_rq)))
|
2008-01-26 03:08:07 +07:00
|
|
|
return 0;
|
|
|
|
|
2008-11-24 23:05:05 +07:00
|
|
|
for_each_cpu(cpu, this_rq->rd->rto_mask) {
|
2008-01-26 03:08:07 +07:00
|
|
|
if (this_cpu == cpu)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
src_rq = cpu_rq(cpu);
|
2008-12-29 21:39:50 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't bother taking the src_rq->lock if the next highest
|
|
|
|
* task is known to be lower-priority than our current task.
|
|
|
|
* This may look racy, but if this value is about to go
|
|
|
|
* logically higher, the src_rq will push this task away.
|
|
|
|
* And if its going logically lower, we do not care
|
|
|
|
*/
|
|
|
|
if (src_rq->rt.highest_prio.next >=
|
|
|
|
this_rq->rt.highest_prio.curr)
|
|
|
|
continue;
|
|
|
|
|
2008-01-26 03:08:07 +07:00
|
|
|
/*
|
|
|
|
* We can potentially drop this_rq's lock in
|
|
|
|
* double_lock_balance, and another CPU could
|
2008-12-29 21:39:49 +07:00
|
|
|
* alter this_rq
|
2008-01-26 03:08:07 +07:00
|
|
|
*/
|
2008-12-29 21:39:49 +07:00
|
|
|
double_lock_balance(this_rq, src_rq);
|
2008-01-26 03:08:07 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Are there still pullable RT tasks?
|
|
|
|
*/
|
2008-01-26 03:08:30 +07:00
|
|
|
if (src_rq->rt.rt_nr_running <= 1)
|
|
|
|
goto skip;
|
2008-01-26 03:08:07 +07:00
|
|
|
|
|
|
|
p = pick_next_highest_task_rt(src_rq, this_cpu);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do we have an RT task that preempts
|
|
|
|
* the to-be-scheduled task?
|
|
|
|
*/
|
2008-12-29 21:39:49 +07:00
|
|
|
if (p && (p->prio < this_rq->rt.highest_prio.curr)) {
|
2008-01-26 03:08:07 +07:00
|
|
|
WARN_ON(p == src_rq->curr);
|
|
|
|
WARN_ON(!p->se.on_rq);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There's a chance that p is higher in priority
|
|
|
|
* than what's currently running on its cpu.
|
|
|
|
* This is just that p is wakeing up and hasn't
|
|
|
|
* had a chance to schedule. We only pull
|
|
|
|
* p if it is lower in priority than the
|
2008-12-29 21:39:49 +07:00
|
|
|
* current task on the run queue
|
2008-01-26 03:08:07 +07:00
|
|
|
*/
|
2008-12-29 21:39:49 +07:00
|
|
|
if (p->prio < src_rq->curr->prio)
|
2008-01-26 03:08:30 +07:00
|
|
|
goto skip;
|
2008-01-26 03:08:07 +07:00
|
|
|
|
|
|
|
ret = 1;
|
|
|
|
|
|
|
|
deactivate_task(src_rq, p, 0);
|
|
|
|
set_task_cpu(p, this_cpu);
|
|
|
|
activate_task(this_rq, p, 0);
|
|
|
|
/*
|
|
|
|
* We continue with the search, just in
|
|
|
|
* case there's an even higher prio task
|
|
|
|
* in another runqueue. (low likelyhood
|
|
|
|
* but possible)
|
|
|
|
*/
|
|
|
|
}
|
2008-01-26 03:08:30 +07:00
|
|
|
skip:
|
2008-08-11 14:30:22 +07:00
|
|
|
double_unlock_balance(this_rq, src_rq);
|
2008-01-26 03:08:07 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:22 +07:00
|
|
|
static void pre_schedule_rt(struct rq *rq, struct task_struct *prev)
|
2008-01-26 03:08:07 +07:00
|
|
|
{
|
|
|
|
/* Try to pull RT tasks here if we lower this rq's prio */
|
2008-12-29 21:39:49 +07:00
|
|
|
if (unlikely(rt_task(prev)) && rq->rt.highest_prio.curr > prev->prio)
|
2008-01-26 03:08:07 +07:00
|
|
|
pull_rt_task(rq);
|
|
|
|
}
|
|
|
|
|
2008-12-29 21:39:52 +07:00
|
|
|
/*
|
|
|
|
* assumes rq->lock is held
|
|
|
|
*/
|
|
|
|
static int needs_post_schedule_rt(struct rq *rq)
|
|
|
|
{
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
return has_pushable_tasks(rq);
|
2008-12-29 21:39:52 +07:00
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:22 +07:00
|
|
|
static void post_schedule_rt(struct rq *rq)
|
2008-01-26 03:08:05 +07:00
|
|
|
{
|
|
|
|
/*
|
2008-12-29 21:39:52 +07:00
|
|
|
* This is only called if needs_post_schedule_rt() indicates that
|
|
|
|
* we need to push tasks away
|
2008-01-26 03:08:05 +07:00
|
|
|
*/
|
2008-12-29 21:39:52 +07:00
|
|
|
spin_lock_irq(&rq->lock);
|
|
|
|
push_rt_tasks(rq);
|
|
|
|
spin_unlock_irq(&rq->lock);
|
2008-01-26 03:08:05 +07:00
|
|
|
}
|
|
|
|
|
2008-04-23 18:13:29 +07:00
|
|
|
/*
|
|
|
|
* If we are not running and we are not going to reschedule soon, we should
|
|
|
|
* try to push tasks away now
|
|
|
|
*/
|
2008-01-26 03:08:22 +07:00
|
|
|
static void task_wake_up_rt(struct rq *rq, struct task_struct *p)
|
2008-01-26 03:08:07 +07:00
|
|
|
{
|
2008-01-26 03:08:22 +07:00
|
|
|
if (!task_running(rq, p) &&
|
2008-04-23 18:13:29 +07:00
|
|
|
!test_tsk_need_resched(rq->curr) &&
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
has_pushable_tasks(rq) &&
|
2008-12-29 21:39:50 +07:00
|
|
|
p->rt.nr_cpus_allowed > 1)
|
2008-01-26 03:08:07 +07:00
|
|
|
push_rt_tasks(rq);
|
|
|
|
}
|
|
|
|
|
sched: simplify move_tasks()
The move_tasks() function is currently multiplexed with two distinct
capabilities:
1. attempt to move a specified amount of weighted load from one run
queue to another; and
2. attempt to move a specified number of tasks from one run queue to
another.
The first of these capabilities is used in two places, load_balance()
and load_balance_idle(), and in both of these cases the return value of
move_tasks() is used purely to decide if tasks/load were moved and no
notice of the actual number of tasks moved is taken.
The second capability is used in exactly one place,
active_load_balance(), to attempt to move exactly one task and, as
before, the return value is only used as an indicator of success or failure.
This multiplexing of sched_task() was introduced, by me, as part of the
smpnice patches and was motivated by the fact that the alternative, one
function to move specified load and one to move a single task, would
have led to two functions of roughly the same complexity as the old
move_tasks() (or the new balance_tasks()). However, the new modular
design of the new CFS scheduler allows a simpler solution to be adopted
and this patch addresses that solution by:
1. adding a new function, move_one_task(), to be used by
active_load_balance(); and
2. making move_tasks() a single purpose function that tries to move a
specified weighted load and returns 1 for success and 0 for failure.
One of the consequences of these changes is that neither move_one_task()
or the new move_tasks() care how many tasks sched_class.load_balance()
moves and this enables its interface to be simplified by returning the
amount of load moved as its result and removing the load_moved pointer
from the argument list. This helps simplify the new move_tasks() and
slightly reduces the amount of work done in each of
sched_class.load_balance()'s implementations.
Further simplification, e.g. changes to balance_tasks(), are possible
but (slightly) complicated by the special needs of load_balance_fair()
so I've left them to a later patch (if this one gets accepted).
NB Since move_tasks() gets called with two run queue locks held even
small reductions in overhead are worthwhile.
[ mingo@elte.hu ]
this change also reduces code size nicely:
text data bss dec hex filename
39216 3618 24 42858 a76a sched.o.before
39173 3618 24 42815 a73f sched.o.after
Signed-off-by: Peter Williams <pwil3058@bigpond.net.au>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2007-08-09 16:16:46 +07:00
|
|
|
static unsigned long
|
2007-07-09 23:51:58 +07:00
|
|
|
load_balance_rt(struct rq *this_rq, int this_cpu, struct rq *busiest,
|
2007-10-24 23:23:51 +07:00
|
|
|
unsigned long max_load_move,
|
|
|
|
struct sched_domain *sd, enum cpu_idle_type idle,
|
|
|
|
int *all_pinned, int *this_best_prio)
|
2007-07-09 23:51:58 +07:00
|
|
|
{
|
2008-01-26 03:08:07 +07:00
|
|
|
/* don't touch RT tasks */
|
|
|
|
return 0;
|
2007-10-24 23:23:51 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
move_one_task_rt(struct rq *this_rq, int this_cpu, struct rq *busiest,
|
|
|
|
struct sched_domain *sd, enum cpu_idle_type idle)
|
|
|
|
{
|
2008-01-26 03:08:07 +07:00
|
|
|
/* don't touch RT tasks */
|
|
|
|
return 0;
|
2007-07-09 23:51:58 +07:00
|
|
|
}
|
2008-01-26 03:08:15 +07:00
|
|
|
|
2008-03-27 04:23:49 +07:00
|
|
|
static void set_cpus_allowed_rt(struct task_struct *p,
|
2008-11-24 23:05:14 +07:00
|
|
|
const struct cpumask *new_mask)
|
2008-01-26 03:08:07 +07:00
|
|
|
{
|
2008-11-24 23:05:14 +07:00
|
|
|
int weight = cpumask_weight(new_mask);
|
2008-01-26 03:08:07 +07:00
|
|
|
|
|
|
|
BUG_ON(!rt_task(p));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Update the migration status of the RQ if we have an RT task
|
|
|
|
* which is running AND changing its weight value.
|
|
|
|
*/
|
2008-01-26 03:08:30 +07:00
|
|
|
if (p->se.on_rq && (weight != p->rt.nr_cpus_allowed)) {
|
2008-01-26 03:08:07 +07:00
|
|
|
struct rq *rq = task_rq(p);
|
|
|
|
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
if (!task_current(rq, p)) {
|
|
|
|
/*
|
|
|
|
* Make sure we dequeue this task from the pushable list
|
|
|
|
* before going further. It will either remain off of
|
|
|
|
* the list because we are no longer pushable, or it
|
|
|
|
* will be requeued.
|
|
|
|
*/
|
|
|
|
if (p->rt.nr_cpus_allowed > 1)
|
|
|
|
dequeue_pushable_task(rq, p);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Requeue if our weight is changing and still > 1
|
|
|
|
*/
|
|
|
|
if (weight > 1)
|
|
|
|
enqueue_pushable_task(rq, p);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:30 +07:00
|
|
|
if ((p->rt.nr_cpus_allowed <= 1) && (weight > 1)) {
|
2008-01-26 03:08:07 +07:00
|
|
|
rq->rt.rt_nr_migratory++;
|
2008-01-26 03:08:30 +07:00
|
|
|
} else if ((p->rt.nr_cpus_allowed > 1) && (weight <= 1)) {
|
2008-01-26 03:08:07 +07:00
|
|
|
BUG_ON(!rq->rt.rt_nr_migratory);
|
|
|
|
rq->rt.rt_nr_migratory--;
|
|
|
|
}
|
|
|
|
|
|
|
|
update_rt_migration(rq);
|
|
|
|
}
|
|
|
|
|
2008-11-24 23:05:14 +07:00
|
|
|
cpumask_copy(&p->cpus_allowed, new_mask);
|
2008-01-26 03:08:30 +07:00
|
|
|
p->rt.nr_cpus_allowed = weight;
|
2008-01-26 03:08:07 +07:00
|
|
|
}
|
2008-01-26 03:08:15 +07:00
|
|
|
|
2008-01-26 03:08:18 +07:00
|
|
|
/* Assumes rq->lock is held */
|
2008-06-05 02:04:05 +07:00
|
|
|
static void rq_online_rt(struct rq *rq)
|
2008-01-26 03:08:18 +07:00
|
|
|
{
|
|
|
|
if (rq->rt.overloaded)
|
|
|
|
rt_set_overload(rq);
|
2008-05-13 02:21:01 +07:00
|
|
|
|
2008-06-05 19:49:58 +07:00
|
|
|
__enable_runtime(rq);
|
|
|
|
|
2008-12-29 21:39:49 +07:00
|
|
|
cpupri_set(&rq->rd->cpupri, rq->cpu, rq->rt.highest_prio.curr);
|
2008-01-26 03:08:18 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Assumes rq->lock is held */
|
2008-06-05 02:04:05 +07:00
|
|
|
static void rq_offline_rt(struct rq *rq)
|
2008-01-26 03:08:18 +07:00
|
|
|
{
|
|
|
|
if (rq->rt.overloaded)
|
|
|
|
rt_clear_overload(rq);
|
2008-05-13 02:21:01 +07:00
|
|
|
|
2008-06-05 19:49:58 +07:00
|
|
|
__disable_runtime(rq);
|
|
|
|
|
2008-05-13 02:21:01 +07:00
|
|
|
cpupri_set(&rq->rd->cpupri, rq->cpu, CPUPRI_INVALID);
|
2008-01-26 03:08:18 +07:00
|
|
|
}
|
2008-01-26 03:08:22 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* When switch from the rt queue, we bring ourselves to a position
|
|
|
|
* that we might want to pull RT tasks from other runqueues.
|
|
|
|
*/
|
|
|
|
static void switched_from_rt(struct rq *rq, struct task_struct *p,
|
|
|
|
int running)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If there are other RT tasks then we will reschedule
|
|
|
|
* and the scheduling of the other RT tasks will handle
|
|
|
|
* the balancing. But if we are the last RT task
|
|
|
|
* we may need to handle the pulling of RT tasks
|
|
|
|
* now.
|
|
|
|
*/
|
|
|
|
if (!rq->rt.rt_nr_running)
|
|
|
|
pull_rt_task(rq);
|
|
|
|
}
|
2008-11-25 06:28:41 +07:00
|
|
|
|
|
|
|
static inline void init_sched_rt_class(void)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
for_each_possible_cpu(i)
|
2009-01-01 09:08:45 +07:00
|
|
|
alloc_cpumask_var_node(&per_cpu(local_cpu_mask, i),
|
|
|
|
GFP_KERNEL, cpu_to_node(i));
|
2008-11-25 06:28:41 +07:00
|
|
|
}
|
2008-01-26 03:08:22 +07:00
|
|
|
#endif /* CONFIG_SMP */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When switching a task to RT, we may overload the runqueue
|
|
|
|
* with RT tasks. In this case we try to push them off to
|
|
|
|
* other runqueues.
|
|
|
|
*/
|
|
|
|
static void switched_to_rt(struct rq *rq, struct task_struct *p,
|
|
|
|
int running)
|
|
|
|
{
|
|
|
|
int check_resched = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we are already running, then there's nothing
|
|
|
|
* that needs to be done. But if we are not running
|
|
|
|
* we may need to preempt the current running task.
|
|
|
|
* If that current running task is also an RT task
|
|
|
|
* then see if we can move to another run queue.
|
|
|
|
*/
|
|
|
|
if (!running) {
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
if (rq->rt.overloaded && push_rt_task(rq) &&
|
|
|
|
/* Don't resched if we changed runqueues */
|
|
|
|
rq != task_rq(p))
|
|
|
|
check_resched = 0;
|
|
|
|
#endif /* CONFIG_SMP */
|
|
|
|
if (check_resched && p->prio < rq->curr->prio)
|
|
|
|
resched_task(rq->curr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Priority of the task has changed. This may cause
|
|
|
|
* us to initiate a push or pull.
|
|
|
|
*/
|
|
|
|
static void prio_changed_rt(struct rq *rq, struct task_struct *p,
|
|
|
|
int oldprio, int running)
|
|
|
|
{
|
|
|
|
if (running) {
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
/*
|
|
|
|
* If our priority decreases while running, we
|
|
|
|
* may need to pull tasks to this runqueue.
|
|
|
|
*/
|
|
|
|
if (oldprio < p->prio)
|
|
|
|
pull_rt_task(rq);
|
|
|
|
/*
|
|
|
|
* If there's a higher priority task waiting to run
|
2008-03-05 22:00:12 +07:00
|
|
|
* then reschedule. Note, the above pull_rt_task
|
|
|
|
* can release the rq lock and p could migrate.
|
|
|
|
* Only reschedule if p is still on the same runqueue.
|
2008-01-26 03:08:22 +07:00
|
|
|
*/
|
2008-12-29 21:39:49 +07:00
|
|
|
if (p->prio > rq->rt.highest_prio.curr && rq->curr == p)
|
2008-01-26 03:08:22 +07:00
|
|
|
resched_task(p);
|
|
|
|
#else
|
|
|
|
/* For UP simply resched on drop of prio */
|
|
|
|
if (oldprio < p->prio)
|
|
|
|
resched_task(p);
|
2008-01-26 03:08:05 +07:00
|
|
|
#endif /* CONFIG_SMP */
|
2008-01-26 03:08:22 +07:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* This task is not running, but if it is
|
|
|
|
* greater than the current running task
|
|
|
|
* then reschedule.
|
|
|
|
*/
|
|
|
|
if (p->prio < rq->curr->prio)
|
|
|
|
resched_task(rq->curr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-01-26 03:08:27 +07:00
|
|
|
static void watchdog(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
|
|
|
unsigned long soft, hard;
|
|
|
|
|
|
|
|
if (!p->signal)
|
|
|
|
return;
|
|
|
|
|
|
|
|
soft = p->signal->rlim[RLIMIT_RTTIME].rlim_cur;
|
|
|
|
hard = p->signal->rlim[RLIMIT_RTTIME].rlim_max;
|
|
|
|
|
|
|
|
if (soft != RLIM_INFINITY) {
|
|
|
|
unsigned long next;
|
|
|
|
|
|
|
|
p->rt.timeout++;
|
|
|
|
next = DIV_ROUND_UP(min(soft, hard), USEC_PER_SEC/HZ);
|
2008-01-26 03:08:32 +07:00
|
|
|
if (p->rt.timeout > next)
|
timers: fix itimer/many thread hang
Overview
This patch reworks the handling of POSIX CPU timers, including the
ITIMER_PROF, ITIMER_VIRT timers and rlimit handling. It was put together
with the help of Roland McGrath, the owner and original writer of this code.
The problem we ran into, and the reason for this rework, has to do with using
a profiling timer in a process with a large number of threads. It appears
that the performance of the old implementation of run_posix_cpu_timers() was
at least O(n*3) (where "n" is the number of threads in a process) or worse.
Everything is fine with an increasing number of threads until the time taken
for that routine to run becomes the same as or greater than the tick time, at
which point things degrade rather quickly.
This patch fixes bug 9906, "Weird hang with NPTL and SIGPROF."
Code Changes
This rework corrects the implementation of run_posix_cpu_timers() to make it
run in constant time for a particular machine. (Performance may vary between
one machine and another depending upon whether the kernel is built as single-
or multiprocessor and, in the latter case, depending upon the number of
running processors.) To do this, at each tick we now update fields in
signal_struct as well as task_struct. The run_posix_cpu_timers() function
uses those fields to make its decisions.
We define a new structure, "task_cputime," to contain user, system and
scheduler times and use these in appropriate places:
struct task_cputime {
cputime_t utime;
cputime_t stime;
unsigned long long sum_exec_runtime;
};
This is included in the structure "thread_group_cputime," which is a new
substructure of signal_struct and which varies for uniprocessor versus
multiprocessor kernels. For uniprocessor kernels, it uses "task_cputime" as
a simple substructure, while for multiprocessor kernels it is a pointer:
struct thread_group_cputime {
struct task_cputime totals;
};
struct thread_group_cputime {
struct task_cputime *totals;
};
We also add a new task_cputime substructure directly to signal_struct, to
cache the earliest expiration of process-wide timers, and task_cputime also
replaces the it_*_expires fields of task_struct (used for earliest expiration
of thread timers). The "thread_group_cputime" structure contains process-wide
timers that are updated via account_user_time() and friends. In the non-SMP
case the structure is a simple aggregator; unfortunately in the SMP case that
simplicity was not achievable due to cache-line contention between CPUs (in
one measured case performance was actually _worse_ on a 16-cpu system than
the same test on a 4-cpu system, due to this contention). For SMP, the
thread_group_cputime counters are maintained as a per-cpu structure allocated
using alloc_percpu(). The timer functions update only the timer field in
the structure corresponding to the running CPU, obtained using per_cpu_ptr().
We define a set of inline functions in sched.h that we use to maintain the
thread_group_cputime structure and hide the differences between UP and SMP
implementations from the rest of the kernel. The thread_group_cputime_init()
function initializes the thread_group_cputime structure for the given task.
The thread_group_cputime_alloc() is a no-op for UP; for SMP it calls the
out-of-line function thread_group_cputime_alloc_smp() to allocate and fill
in the per-cpu structures and fields. The thread_group_cputime_free()
function, also a no-op for UP, in SMP frees the per-cpu structures. The
thread_group_cputime_clone_thread() function (also a UP no-op) for SMP calls
thread_group_cputime_alloc() if the per-cpu structures haven't yet been
allocated. The thread_group_cputime() function fills the task_cputime
structure it is passed with the contents of the thread_group_cputime fields;
in UP it's that simple but in SMP it must also safely check that tsk->signal
is non-NULL (if it is it just uses the appropriate fields of task_struct) and,
if so, sums the per-cpu values for each online CPU. Finally, the three
functions account_group_user_time(), account_group_system_time() and
account_group_exec_runtime() are used by timer functions to update the
respective fields of the thread_group_cputime structure.
Non-SMP operation is trivial and will not be mentioned further.
The per-cpu structure is always allocated when a task creates its first new
thread, via a call to thread_group_cputime_clone_thread() from copy_signal().
It is freed at process exit via a call to thread_group_cputime_free() from
cleanup_signal().
All functions that formerly summed utime/stime/sum_sched_runtime values from
from all threads in the thread group now use thread_group_cputime() to
snapshot the values in the thread_group_cputime structure or the values in
the task structure itself if the per-cpu structure hasn't been allocated.
Finally, the code in kernel/posix-cpu-timers.c has changed quite a bit.
The run_posix_cpu_timers() function has been split into a fast path and a
slow path; the former safely checks whether there are any expired thread
timers and, if not, just returns, while the slow path does the heavy lifting.
With the dedicated thread group fields, timers are no longer "rebalanced" and
the process_timer_rebalance() function and related code has gone away. All
summing loops are gone and all code that used them now uses the
thread_group_cputime() inline. When process-wide timers are set, the new
task_cputime structure in signal_struct is used to cache the earliest
expiration; this is checked in the fast path.
Performance
The fix appears not to add significant overhead to existing operations. It
generally performs the same as the current code except in two cases, one in
which it performs slightly worse (Case 5 below) and one in which it performs
very significantly better (Case 2 below). Overall it's a wash except in those
two cases.
I've since done somewhat more involved testing on a dual-core Opteron system.
Case 1: With no itimer running, for a test with 100,000 threads, the fixed
kernel took 1428.5 seconds, 513 seconds more than the unfixed system,
all of which was spent in the system. There were twice as many
voluntary context switches with the fix as without it.
Case 2: With an itimer running at .01 second ticks and 4000 threads (the most
an unmodified kernel can handle), the fixed kernel ran the test in
eight percent of the time (5.8 seconds as opposed to 70 seconds) and
had better tick accuracy (.012 seconds per tick as opposed to .023
seconds per tick).
Case 3: A 4000-thread test with an initial timer tick of .01 second and an
interval of 10,000 seconds (i.e. a timer that ticks only once) had
very nearly the same performance in both cases: 6.3 seconds elapsed
for the fixed kernel versus 5.5 seconds for the unfixed kernel.
With fewer threads (eight in these tests), the Case 1 test ran in essentially
the same time on both the modified and unmodified kernels (5.2 seconds versus
5.8 seconds). The Case 2 test ran in about the same time as well, 5.9 seconds
versus 5.4 seconds but again with much better tick accuracy, .013 seconds per
tick versus .025 seconds per tick for the unmodified kernel.
Since the fix affected the rlimit code, I also tested soft and hard CPU limits.
Case 4: With a hard CPU limit of 20 seconds and eight threads (and an itimer
running), the modified kernel was very slightly favored in that while
it killed the process in 19.997 seconds of CPU time (5.002 seconds of
wall time), only .003 seconds of that was system time, the rest was
user time. The unmodified kernel killed the process in 20.001 seconds
of CPU (5.014 seconds of wall time) of which .016 seconds was system
time. Really, though, the results were too close to call. The results
were essentially the same with no itimer running.
Case 5: With a soft limit of 20 seconds and a hard limit of 2000 seconds
(where the hard limit would never be reached) and an itimer running,
the modified kernel exhibited worse tick accuracy than the unmodified
kernel: .050 seconds/tick versus .028 seconds/tick. Otherwise,
performance was almost indistinguishable. With no itimer running this
test exhibited virtually identical behavior and times in both cases.
In times past I did some limited performance testing. those results are below.
On a four-cpu Opteron system without this fix, a sixteen-thread test executed
in 3569.991 seconds, of which user was 3568.435s and system was 1.556s. On
the same system with the fix, user and elapsed time were about the same, but
system time dropped to 0.007 seconds. Performance with eight, four and one
thread were comparable. Interestingly, the timer ticks with the fix seemed
more accurate: The sixteen-thread test with the fix received 149543 ticks
for 0.024 seconds per tick, while the same test without the fix received 58720
for 0.061 seconds per tick. Both cases were configured for an interval of
0.01 seconds. Again, the other tests were comparable. Each thread in this
test computed the primes up to 25,000,000.
I also did a test with a large number of threads, 100,000 threads, which is
impossible without the fix. In this case each thread computed the primes only
up to 10,000 (to make the runtime manageable). System time dominated, at
1546.968 seconds out of a total 2176.906 seconds (giving a user time of
629.938s). It received 147651 ticks for 0.015 seconds per tick, still quite
accurate. There is obviously no comparable test without the fix.
Signed-off-by: Frank Mayhar <fmayhar@google.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-09-12 23:54:39 +07:00
|
|
|
p->cputime_expires.sched_exp = p->se.sum_exec_runtime;
|
2008-01-26 03:08:27 +07:00
|
|
|
}
|
|
|
|
}
|
2007-07-09 23:51:58 +07:00
|
|
|
|
2008-01-26 03:08:29 +07:00
|
|
|
static void task_tick_rt(struct rq *rq, struct task_struct *p, int queued)
|
2007-07-09 23:51:58 +07:00
|
|
|
{
|
2007-12-20 21:01:17 +07:00
|
|
|
update_curr_rt(rq);
|
|
|
|
|
2008-01-26 03:08:27 +07:00
|
|
|
watchdog(rq, p);
|
|
|
|
|
2007-07-09 23:51:58 +07:00
|
|
|
/*
|
|
|
|
* RR tasks need a special form of timeslice management.
|
|
|
|
* FIFO tasks have no timeslices.
|
|
|
|
*/
|
|
|
|
if (p->policy != SCHED_RR)
|
|
|
|
return;
|
|
|
|
|
2008-01-26 03:08:27 +07:00
|
|
|
if (--p->rt.time_slice)
|
2007-07-09 23:51:58 +07:00
|
|
|
return;
|
|
|
|
|
2008-01-26 03:08:27 +07:00
|
|
|
p->rt.time_slice = DEF_TIMESLICE;
|
2007-07-09 23:51:58 +07:00
|
|
|
|
2007-08-25 01:39:10 +07:00
|
|
|
/*
|
|
|
|
* Requeue to the end of queue if we are not the only element
|
|
|
|
* on the queue:
|
|
|
|
*/
|
2008-01-26 03:08:27 +07:00
|
|
|
if (p->rt.run_list.prev != p->rt.run_list.next) {
|
2008-07-02 04:32:15 +07:00
|
|
|
requeue_task_rt(rq, p, 0);
|
2007-08-25 01:39:10 +07:00
|
|
|
set_tsk_need_resched(p);
|
|
|
|
}
|
2007-07-09 23:51:58 +07:00
|
|
|
}
|
|
|
|
|
2007-10-15 22:00:08 +07:00
|
|
|
static void set_curr_task_rt(struct rq *rq)
|
|
|
|
{
|
|
|
|
struct task_struct *p = rq->curr;
|
|
|
|
|
|
|
|
p->se.exec_start = rq->clock;
|
sched: create "pushable_tasks" list to limit pushing to one attempt
The RT scheduler employs a "push/pull" design to actively balance tasks
within the system (on a per disjoint cpuset basis). When a task is
awoken, it is immediately determined if there are any lower priority
cpus which should be preempted. This is opposed to the way normal
SCHED_OTHER tasks behave, which will wait for a periodic rebalancing
operation to occur before spreading out load.
When a particular RQ has more than 1 active RT task, it is said to
be in an "overloaded" state. Once this occurs, the system enters
the active balancing mode, where it will try to push the task away,
or persuade a different cpu to pull it over. The system will stay
in this state until the system falls back below the <= 1 queued RT
task per RQ.
However, the current implementation suffers from a limitation in the
push logic. Once overloaded, all tasks (other than current) on the
RQ are analyzed on every push operation, even if it was previously
unpushable (due to affinity, etc). Whats more, the operation stops
at the first task that is unpushable and will not look at items
lower in the queue. This causes two problems:
1) We can have the same tasks analyzed over and over again during each
push, which extends out the fast path in the scheduler for no
gain. Consider a RQ that has dozens of tasks that are bound to a
core. Each one of those tasks will be encountered and skipped
for each push operation while they are queued.
2) There may be lower-priority tasks under the unpushable task that
could have been successfully pushed, but will never be considered
until either the unpushable task is cleared, or a pull operation
succeeds. The net result is a potential latency source for mid
priority tasks.
This patch aims to rectify these two conditions by introducing a new
priority sorted list: "pushable_tasks". A task is added to the list
each time a task is activated or preempted. It is removed from the
list any time it is deactivated, made current, or fails to push.
This works because a task only needs to be attempted to push once.
After an initial failure to push, the other cpus will eventually try to
pull the task when the conditions are proper. This also solves the
problem that we don't completely analyze all tasks due to encountering
an unpushable tasks. Now every task will have a push attempted (when
appropriate).
This reduces latency both by shorting the critical section of the
rq->lock for certain workloads, and by making sure the algorithm
considers all eligible tasks in the system.
[ rostedt: added a couple more BUG_ONs ]
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
2008-12-29 21:39:53 +07:00
|
|
|
|
|
|
|
/* The running task is never eligible for pushing */
|
|
|
|
dequeue_pushable_task(rq, p);
|
2007-10-15 22:00:08 +07:00
|
|
|
}
|
|
|
|
|
2008-04-26 00:53:13 +07:00
|
|
|
static const struct sched_class rt_sched_class = {
|
2007-10-15 22:00:12 +07:00
|
|
|
.next = &fair_sched_class,
|
2007-07-09 23:51:58 +07:00
|
|
|
.enqueue_task = enqueue_task_rt,
|
|
|
|
.dequeue_task = dequeue_task_rt,
|
|
|
|
.yield_task = yield_task_rt,
|
|
|
|
|
|
|
|
.check_preempt_curr = check_preempt_curr_rt,
|
|
|
|
|
|
|
|
.pick_next_task = pick_next_task_rt,
|
|
|
|
.put_prev_task = put_prev_task_rt,
|
|
|
|
|
2007-10-24 23:23:51 +07:00
|
|
|
#ifdef CONFIG_SMP
|
2008-10-22 14:25:26 +07:00
|
|
|
.select_task_rq = select_task_rq_rt,
|
|
|
|
|
2007-07-09 23:51:58 +07:00
|
|
|
.load_balance = load_balance_rt,
|
2007-10-24 23:23:51 +07:00
|
|
|
.move_one_task = move_one_task_rt,
|
2008-01-26 03:08:07 +07:00
|
|
|
.set_cpus_allowed = set_cpus_allowed_rt,
|
2008-06-05 02:04:05 +07:00
|
|
|
.rq_online = rq_online_rt,
|
|
|
|
.rq_offline = rq_offline_rt,
|
2008-01-26 03:08:22 +07:00
|
|
|
.pre_schedule = pre_schedule_rt,
|
2008-12-29 21:39:52 +07:00
|
|
|
.needs_post_schedule = needs_post_schedule_rt,
|
2008-01-26 03:08:22 +07:00
|
|
|
.post_schedule = post_schedule_rt,
|
|
|
|
.task_wake_up = task_wake_up_rt,
|
2008-01-26 03:08:22 +07:00
|
|
|
.switched_from = switched_from_rt,
|
2007-10-24 23:23:51 +07:00
|
|
|
#endif
|
2007-07-09 23:51:58 +07:00
|
|
|
|
2007-10-15 22:00:08 +07:00
|
|
|
.set_curr_task = set_curr_task_rt,
|
2007-07-09 23:51:58 +07:00
|
|
|
.task_tick = task_tick_rt,
|
2008-01-26 03:08:22 +07:00
|
|
|
|
|
|
|
.prio_changed = prio_changed_rt,
|
|
|
|
.switched_to = switched_to_rt,
|
2007-07-09 23:51:58 +07:00
|
|
|
};
|
2008-06-19 19:22:24 +07:00
|
|
|
|
|
|
|
#ifdef CONFIG_SCHED_DEBUG
|
|
|
|
extern void print_rt_rq(struct seq_file *m, int cpu, struct rt_rq *rt_rq);
|
|
|
|
|
|
|
|
static void print_rt_stats(struct seq_file *m, int cpu)
|
|
|
|
{
|
|
|
|
struct rt_rq *rt_rq;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
for_each_leaf_rt_rq(rt_rq, cpu_rq(cpu))
|
|
|
|
print_rt_rq(m, cpu, rt_rq);
|
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
2008-06-25 01:09:43 +07:00
|
|
|
#endif /* CONFIG_SCHED_DEBUG */
|
2008-11-24 23:05:13 +07:00
|
|
|
|