[RFC] sched: check RT runqueue overloaded in tick timer

[RFC] sched: check RT runqueue overloaded in tick timer

[Hillf Danton]

Hi Steven

When tick timer runs, runqueue overload is checked. If overloaded and other
CPUs available at the moment, reschedule is fired to allow push logic to move
the pushable tasks somewhere else.

Thanks

Hillf
---
 kernel/sched_rt.c |   21 +++++++++++++++++++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
index b03cd89..afd29a3 100644
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -1767,10 +1767,10 @@ static void task_tick_rt(struct rq *rq, struct
task_struct *p, int queued)
 	 * FIFO tasks have no timeslices.
 	 */
 	if (p->policy != SCHED_RR)
-		return;
+		goto check_overload;

 	if (--p->rt.time_slice)
-		return;
+		goto check_overload;

 	p->rt.time_slice = DEF_TIMESLICE;

@@ -1782,6 +1782,23 @@ static void task_tick_rt(struct rq *rq, struct
task_struct *p, int queued)
 		requeue_task_rt(rq, p, 0);
 		set_tsk_need_resched(p);
 	}
+
+check_overload:
+#ifdef CONFIG_SMP
+	if (!test_tsk_need_resched(p)) {
+		struct task_struct *t = pick_next_pushable_task(rq);
+		/*
+		 * If @rq overloaded and other CPUs available, reschedule
+		 * @p to allow the push logic to move the pushable tasks
+		 * somewhere else.
+		 *
+		 * It is a pseudo schedule, since @p, without accident, will
+		 * be picked again. If not, fine:)
+		 */
+		if (t && cpupri_find(&rq->rd->cpupri, t, NULL))
+			set_tsk_need_resched(p);
+	}
+#endif
 }

 static void set_curr_task_rt(struct rq *rq)

Re: [RFC] sched: check RT runqueue overloaded in tick timer

[Steven Rostedt]

On Thu, 2011-06-30 at 20:47 +0800, Hillf Danton wrote:
> Hi Steven
> 
> When tick timer runs, runqueue overload is checked. If overloaded and other
> CPUs available at the moment, reschedule is fired to allow push logic to move
> the pushable tasks somewhere else.

Why?

This would be a waste of overhead. We check when a task is queued and
dequeue, and when a cpu lowers its priority (for a pull). There's no
need to randomly check if we need to push or pull based on timers.
That's just going to slow things down.

-- Steve

> 
> Thanks
> 
> Hillf
> ---
>  kernel/sched_rt.c |   21 +++++++++++++++++++--
>  1 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
> index b03cd89..afd29a3 100644
> --- a/kernel/sched_rt.c
> +++ b/kernel/sched_rt.c
> @@ -1767,10 +1767,10 @@ static void task_tick_rt(struct rq *rq, struct
> task_struct *p, int queued)
>  	 * FIFO tasks have no timeslices.
>  	 */
>  	if (p->policy != SCHED_RR)
> -		return;
> +		goto check_overload;
> 
>  	if (--p->rt.time_slice)
> -		return;
> +		goto check_overload;
> 
>  	p->rt.time_slice = DEF_TIMESLICE;
> 
> @@ -1782,6 +1782,23 @@ static void task_tick_rt(struct rq *rq, struct
> task_struct *p, int queued)
>  		requeue_task_rt(rq, p, 0);
>  		set_tsk_need_resched(p);
>  	}
> +
> +check_overload:
> +#ifdef CONFIG_SMP
> +	if (!test_tsk_need_resched(p)) {
> +		struct task_struct *t = pick_next_pushable_task(rq);
> +		/*
> +		 * If @rq overloaded and other CPUs available, reschedule
> +		 * @p to allow the push logic to move the pushable tasks
> +		 * somewhere else.
> +		 *
> +		 * It is a pseudo schedule, since @p, without accident, will
> +		 * be picked again. If not, fine:)
> +		 */
> +		if (t && cpupri_find(&rq->rd->cpupri, t, NULL))
> +			set_tsk_need_resched(p);
> +	}
> +#endif
>  }
> 
>  static void set_curr_task_rt(struct rq *rq)

Re: [RFC] sched: check RT runqueue overloaded in tick timer

[Hillf Danton]

On Thu, Jun 30, 2011 at 8:55 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, 2011-06-30 at 20:47 +0800, Hillf Danton wrote:
>> Hi Steven
>>
>> When tick timer runs, runqueue overload is checked. If overloaded and other
>> CPUs available at the moment, reschedule is fired to allow push logic to move
>> the pushable tasks somewhere else.
>
> Why?
>
> This would be a waste of overhead. We check when a task is queued and
> dequeue, and when a cpu lowers its priority (for a pull). There's no
> need to randomly check if we need to push or pull based on timers.
> That's just going to slow things down.
>
Got it.

If puller is inactive, there is no CPU available for the pushable.

Thanks
Hillf