From: "Gregory Haskins" <ghaskins@novell.com>
To: "Dmitry Adamushko" <dmitry.adamushko@gmail.com>,
"Steven Rostedt" <rostedt@goodmis.org>
Cc: <mingo@elte.hu>, <chinang.ma@intel.com>,
<suresh.b.siddha@intel.com>, <arjan@linux.intel.com>,
<willy@linux.intel.com>, <linux-kernel@vger.kernel.org>,
<linux-rt-users@vger.kernel.org>
Subject: Re: [PATCH 1/2] sched: push rt tasks only if newly activated tasks have been added
Date: Wed, 23 Apr 2008 04:03:14 -0600 [thread overview]
Message-ID: <480ED122.BA47.005A.0@novell.com> (raw)
In-Reply-To: <b647ffbd0804230253i32f48fcgb5dc7cf5b55607ac@mail.gmail.com>
>>> On Wed, Apr 23, 2008 at 5:53 AM, in message
<b647ffbd0804230253i32f48fcgb5dc7cf5b55607ac@mail.gmail.com>, "Dmitry
Adamushko" <dmitry.adamushko@gmail.com> wrote:
> 2008/4/23 Dmitry Adamushko <dmitry.adamushko@gmail.com>:
>> Hi Steven,
>>
>> > [ ... ]
>>
>> > > square#0:
>> > >
>> > > cpu1: T0 is running
>> > >
>> > > T1 is of the same prio as T0 (shouldn't really matter but to get the
>> > > same result it would require altering the flow of events slightly)
>> > >
>> > > T1's affinity allows it to be run only on cpu1.
>> > > T0 can run on both.
>> > >
>> > > try_to_wake_up() is called for T1.
>> > > |
>> > > --> select_task_rq_rt() => gives cpu1
>> > > |
>> > > --> task_wake_up_rt()
>> > > |
>> > > ---> push_rt_tasks() -> rq->rt.pushed = 1
>> > >
>> > > now, neither T1 (due to its affinity), nor T0 (it's running) can be
>> > > pushed away to cpu0.
>> >
>> > Ah, this may be what you are talking about. T0 was running, but because
>> > T1 has its affinity set to cpu1 it wont cause a push. When T0 schedules
>> > away to give T1 its cpu time, T0 wont push away because of the pushed
>> > flag.
>> >
>> > Hmm, interesting. Of course my response is "Don't use SCHED_RR! It's
>> > evil!" ;-)
>>
>> It's not just SCHED_RR ;-) They both can be of SCHED_FIFO.
>>
>> T1 _preempts_ T0 and again
>>
>>
>> --> task_wake_up_rt()
>> |
>> ---> push_rt_tasks() -> rq->rt.pushed = 1
>>
>> and T0 won't be pushed away to cpu0 by post_schedule_rt().
>>
>> As Gregory has pointed out, at the very least it's a test in
>> task_wake_up_rt() which is wrong.
>>
>> push_rt_tasks() should not be called when 'p' (a newly woken up task)
>> is the next one to run.
>>
>> IOW, it should be (p->prio < rq->curr->prio) instead of (p->prio >=
>> rq->rt.highest_prio).
>
> No, this argument is wrong indeed.
>
> Something like this:
> (white-spaces are broken)
>
> --- sched_rt-prev.c 2008-04-23 11:26:39.000000000 +0200
> +++ sched_rt.c 2008-04-23 11:36:20.000000000 +0200
> @@ -1121,9 +1121,13 @@ static void post_schedule_rt(struct rq *
>
> static void task_wake_up_rt(struct rq *rq, struct task_struct *p)
> {
> - if (!task_running(rq, p) &&
> - (p->prio >= rq->rt.highest_prio) &&
> - rq->rt.overloaded)
> + /*
> + * Consider pushing 'p' off to other CPUS only
> + * if it's not the next task to run on this CPU.
> + */
> + if (rq->rt.overloaded &&
> + p->prio > rq->rt.highest_prio &&
> + pick_rt_task(rq, p, -1))
> push_rt_tasks(rq);
> }
>
>
> or even this (although, it's a bit heavier)
>
> --- sched_rt-prev.c 2008-04-23 11:26:39.000000000 +0200
> +++ sched_rt.c 2008-04-23 11:49:03.000000000 +0200
> @@ -1118,12 +1118,22 @@ static void post_schedule_rt(struct rq *
> }
> }
>
> static void task_wake_up_rt(struct rq *rq, struct task_struct *p)
> {
> - if (!task_running(rq, p) &&
> - (p->prio >= rq->rt.highest_prio) &&
> - rq->rt.overloaded)
> + if (!rq->rt.overloaded)
> + return;
> +
> + /*
> + * Consider pushing 'p' off to other CPUS only
> + * if it's not the next task to run on this CPU.
> + * i.e. it's not a single task with the highest prio
> + * on the queue.
> + */
> + if (p->prio == rq->rt.highest_prio &&
> + p->rt.run_list.prev == p->rt.run_list.next)
> + return;
> +
> + if (pick_rt_task(rq, p, -1))
> push_rt_tasks(rq);
> }
>
I think we can simplify this further. We really only need to push here if we are not going to reschedule anytime soon (probably white-space damaged):
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -1058,11 +1058,14 @@ static void post_schedule_rt(struct rq *rq)
}
}
WARNING: multiple messages have this Message-ID (diff)
From: "Gregory Haskins" <ghaskins@novell.com>
To: "Dmitry Adamushko" <dmitry.adamushko@gmail.com>,
"Steven Rostedt" <rostedt@goodmis.org>
Cc: <mingo@elte.hu>, <chinang.ma@intel.com>,
<suresh.b.siddha@intel.com>, <arjan@linux.intel.com>,
<willy@linux.intel.com>, <linux-kernel@vger.kernel.org>,
<linux-rt-users@vger.kernel.org>
Subject: Re: [PATCH 1/2] sched: push rt tasks only if newly activated tasks have been added
Date: Wed, 23 Apr 2008 04:03:14 -0600 [thread overview]
Message-ID: <480ED122.BA47.005A.0@novell.com> (raw)
In-Reply-To: <b647ffbd0804230253i32f48fcgb5dc7cf5b55607ac@mail.gmail.com>
>>> On Wed, Apr 23, 2008 at 5:53 AM, in message
<b647ffbd0804230253i32f48fcgb5dc7cf5b55607ac@mail.gmail.com>, "Dmitry
Adamushko" <dmitry.adamushko@gmail.com> wrote:
> 2008/4/23 Dmitry Adamushko <dmitry.adamushko@gmail.com>:
>> Hi Steven,
>>
>> > [ ... ]
>>
>> > > square#0:
>> > >
>> > > cpu1: T0 is running
>> > >
>> > > T1 is of the same prio as T0 (shouldn't really matter but to get the
>> > > same result it would require altering the flow of events slightly)
>> > >
>> > > T1's affinity allows it to be run only on cpu1.
>> > > T0 can run on both.
>> > >
>> > > try_to_wake_up() is called for T1.
>> > > |
>> > > --> select_task_rq_rt() => gives cpu1
>> > > |
>> > > --> task_wake_up_rt()
>> > > |
>> > > ---> push_rt_tasks() -> rq->rt.pushed = 1
>> > >
>> > > now, neither T1 (due to its affinity), nor T0 (it's running) can be
>> > > pushed away to cpu0.
>> >
>> > Ah, this may be what you are talking about. T0 was running, but because
>> > T1 has its affinity set to cpu1 it wont cause a push. When T0 schedules
>> > away to give T1 its cpu time, T0 wont push away because of the pushed
>> > flag.
>> >
>> > Hmm, interesting. Of course my response is "Don't use SCHED_RR! It's
>> > evil!" ;-)
>>
>> It's not just SCHED_RR ;-) They both can be of SCHED_FIFO.
>>
>> T1 _preempts_ T0 and again
>>
>>
>> --> task_wake_up_rt()
>> |
>> ---> push_rt_tasks() -> rq->rt.pushed = 1
>>
>> and T0 won't be pushed away to cpu0 by post_schedule_rt().
>>
>> As Gregory has pointed out, at the very least it's a test in
>> task_wake_up_rt() which is wrong.
>>
>> push_rt_tasks() should not be called when 'p' (a newly woken up task)
>> is the next one to run.
>>
>> IOW, it should be (p->prio < rq->curr->prio) instead of (p->prio >=
>> rq->rt.highest_prio).
>
> No, this argument is wrong indeed.
>
> Something like this:
> (white-spaces are broken)
>
> --- sched_rt-prev.c 2008-04-23 11:26:39.000000000 +0200
> +++ sched_rt.c 2008-04-23 11:36:20.000000000 +0200
> @@ -1121,9 +1121,13 @@ static void post_schedule_rt(struct rq *
>
> static void task_wake_up_rt(struct rq *rq, struct task_struct *p)
> {
> - if (!task_running(rq, p) &&
> - (p->prio >= rq->rt.highest_prio) &&
> - rq->rt.overloaded)
> + /*
> + * Consider pushing 'p' off to other CPUS only
> + * if it's not the next task to run on this CPU.
> + */
> + if (rq->rt.overloaded &&
> + p->prio > rq->rt.highest_prio &&
> + pick_rt_task(rq, p, -1))
> push_rt_tasks(rq);
> }
>
>
> or even this (although, it's a bit heavier)
>
> --- sched_rt-prev.c 2008-04-23 11:26:39.000000000 +0200
> +++ sched_rt.c 2008-04-23 11:49:03.000000000 +0200
> @@ -1118,12 +1118,22 @@ static void post_schedule_rt(struct rq *
> }
> }
>
> static void task_wake_up_rt(struct rq *rq, struct task_struct *p)
> {
> - if (!task_running(rq, p) &&
> - (p->prio >= rq->rt.highest_prio) &&
> - rq->rt.overloaded)
> + if (!rq->rt.overloaded)
> + return;
> +
> + /*
> + * Consider pushing 'p' off to other CPUS only
> + * if it's not the next task to run on this CPU.
> + * i.e. it's not a single task with the highest prio
> + * on the queue.
> + */
> + if (p->prio == rq->rt.highest_prio &&
> + p->rt.run_list.prev == p->rt.run_list.next)
> + return;
> +
> + if (pick_rt_task(rq, p, -1))
> push_rt_tasks(rq);
> }
>
I think we can simplify this further. We really only need to push here if we are not going to reschedule anytime soon (probably white-space damaged):
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -1058,11 +1058,14 @@ static void post_schedule_rt(struct rq *rq)
}
}
-
+/*
+ * If we are not running and we are not going to reschedule soon, we should
+ * try to push tasks away now
+ */
static void task_wake_up_rt(struct rq *rq, struct task_struct *p)
{
if (!task_running(rq, p) &&
- (p->prio >= rq->rt.highest_prio) &&
+ !test_tsk_thread_flag(rq->curr, TIF_NEED_RESCHED) &&
rq->rt.overloaded)
push_rt_tasks(rq);
}
next prev parent reply other threads:[~2008-04-23 10:02 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-21 18:10 [PATCH 0/2] sched: refreshes Gregory Haskins
2008-04-21 18:10 ` [PATCH 1/2] sched: push rt tasks only if newly activated tasks have been added Gregory Haskins
2008-04-22 15:30 ` Dmitry Adamushko
2008-04-22 15:51 ` Steven Rostedt
2008-04-23 8:05 ` Dmitry Adamushko
2008-04-23 9:53 ` Dmitry Adamushko
2008-04-23 10:03 ` Gregory Haskins [this message]
2008-04-23 10:03 ` Gregory Haskins
2008-04-23 10:23 ` Dmitry Adamushko
2008-04-23 10:54 ` Gregory Haskins
2008-04-23 10:54 ` Gregory Haskins
2008-04-23 11:20 ` Dmitry Adamushko
2008-04-22 16:38 ` Gregory Haskins
2008-04-23 11:13 ` [RFC PATCH 0/2] sched fixes for suboptimal balancing Gregory Haskins
2008-04-23 11:13 ` [PATCH 1/2] sched: fix RT task-wakeup logic Gregory Haskins
2008-04-23 11:13 ` Gregory Haskins
2008-04-23 12:54 ` Steven Rostedt
2008-04-23 14:29 ` Dmitry Adamushko
2008-04-24 11:56 ` Gregory Haskins
2008-04-28 16:30 ` [(RESEND) PATCH] " Gregory Haskins
2008-04-28 16:30 ` Gregory Haskins
2008-04-29 14:35 ` Ingo Molnar
2008-04-23 11:13 ` [PATCH 2/2] sched: prioritize non-migratable tasks over migratable ones Gregory Haskins
2008-04-23 12:58 ` Steven Rostedt
2008-04-23 13:11 ` [PATCH 2/2] sched: prioritize non-migratable tasks over migratableones Gregory Haskins
2008-04-28 18:55 ` [RFC PATCH 0/2] sched fixes for suboptimal balancing Ingo Molnar
2008-04-21 18:10 ` [PATCH 2/2] sched: Use a 2-d bitmap for searching lowest-pri CPU Gregory Haskins
2008-04-21 19:33 ` [PATCH 0/2] sched: refreshes Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=480ED122.BA47.005A.0@novell.com \
--to=ghaskins@novell.com \
--cc=arjan@linux.intel.com \
--cc=chinang.ma@intel.com \
--cc=dmitry.adamushko@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=suresh.b.siddha@intel.com \
--cc=willy@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.