Re: [PATCH] sched/rt: Don't pull tasks of throttled rt_rq inpre_schedule_rt()

[Steven Rostedt]

Sorry for the late reply.

On Tue, 2012-12-25 at 12:20 +0400, Kirill Tkhai wrote:
> The patch aims not to pull tasks of throttled rt_rqs
> in pre_schedule_rt() because thay are not able to be
> picked in pick_next_task_rt().
> 
> There are three places where pull_rt_task() is used:
> 
> 1)pre_schedule_rt()
> If we pull a task of a throttled rt_rq it won't be picked
> by pick_next_task_rt(), because throttled tasks are dequeued
> by sched_rt_runtime_exceeded(). So this action is unnecessary.
> 
> 2)prio_changed_rt()
> A pulled task of higher priority leads to reschedule of current
> rq's task. The schedule() will occur with the first hw interrupt
> so there is possibility the throttled rt_rq will unthrottle and
> it will be queued during this time.
> (In case of preemptable kernel schedule() occurs during
> preempt_enable() in call of __task_rq_unlock(). But its lock is
> unlocked so there is no guarantee the rt_rq won't be queued).
> 
> 3)switched_from_rt()
> The same as prio_changed_rt().

These are pretty much hot paths. They are done rather commonly. My
concern is that we are adding overhead here that can be done in a much
less common path.

I'm wondering if we couldn't use the pushable_task list for finding the
next highest rt task. That may even speed up the fast path if we do so.

Then, when an rq gets throttled, which shouldn't be often, we can remove
all the tasks from the pushable_task list, and add them back when the rq
is comes back up.

Then, by just using the pushable_task list, we can achieve this goal.

We have to look to see what prevents us from using that list.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/