From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: John Keeping <john@metanate.com>,
Valentin Schneider <valentin.schneider@arm.com>
Cc: linux-rt-users@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RT] BUG in sched/cpupri.c
Date: Wed, 22 Dec 2021 18:46:57 +0100 [thread overview]
Message-ID: <31a47e99-6de3-76ec-62ad-9c98d092ead5@arm.com> (raw)
In-Reply-To: <20211221164528.3c84543f.john@metanate.com>
On 21.12.21 17:45, John Keeping wrote:
> On Tue, 21 Dec 2021 16:11:34 +0000
> Valentin Schneider <valentin.schneider@arm.com> wrote:
>
>> On 20/12/21 18:35, Dietmar Eggemann wrote:
[...]
>> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
>> index fd7c4f972aaf..7d61ceec1a3b 100644
>> --- a/kernel/sched/deadline.c
>> +++ b/kernel/sched/deadline.c
>> @@ -2467,10 +2467,13 @@ static void switched_from_dl(struct rq *rq, struct task_struct *p)
>> * this is the right place to try to pull some other one
>> * from an overloaded CPU, if any.
>> */
>> - if (!task_on_rq_queued(p) || rq->dl.dl_nr_running)
>> + if (!task_on_rq_queued(p))
>> return;
>>
>> - deadline_queue_pull_task(rq);
>> + if (!rq->dl.dl_nr_running)
>> + deadline_queue_pull_task(rq);
>> + else if (task_current(rq, p) && (p->sched_class < &dl_sched_class))
>> + resched_curr(rq);
>> }
>>
>> /*
>> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
>> index ef8228d19382..1ea2567612fb 100644
>> --- a/kernel/sched/rt.c
>> +++ b/kernel/sched/rt.c
>> @@ -2322,10 +2322,13 @@ static void switched_from_rt(struct rq *rq, struct task_struct *p)
>> * we may need to handle the pulling of RT tasks
>> * now.
>> */
>> - if (!task_on_rq_queued(p) || rq->rt.rt_nr_running)
>> + if (!task_on_rq_queued(p))
>> return;
>>
>> - rt_queue_pull_task(rq);
>> + if (!rq->rt.rt_nr_running)
>> + rt_queue_pull_task(rq);
>> + else if (task_current(rq, p) && (p->sched_class < &rt_sched_class))
>> + resched_curr(rq);
switched_from_rt() -> rt_queue_pull_task(, pull_rt_task)
pull_rt_task()->tell_cpu_to_push()->irq_work_queue_on(&rq->rd->rto_push_work,)
rto_push_irq_work_func() -> push_rt_task(rq, true)
seems to be the only way with pull=true.
In my tests, rq->rt.rt_nr_running seems to be 0 when it happens.
[ 22.288537] CPU3 switched_to_rt: p=[ksoftirqd/3 35]
[ 22.288554] rt_mutex_setprio: CPU3 p=[ksoftirqd/3 35] pi_task=[rcu_preempt 11] queued=1 running=0 prio=98 oldprio=120
[ 22.288636] CPU3 switched_from_rt: p=[ksoftirqd/3 35] rq->rt.rt_nr_running=0
^^^^^^^^^^^^^^^^^^^^^^
[ 22.288649] rt_mutex_setprio: CPU3 p=[ksoftirqd/3 35] queued=1 running=1 prio=120 oldprio=98
[ 22.288681] CPU3 push_rt_task: next_task=[rcu_preempt 11] migr_dis=1 rq->curr=[ksoftirqd/3 35] pull=1
^^^^^^^^^^ ^^^^^^
[ 22.288698] CPU: 3 PID: 35 Comm: ksoftirqd/3 Not tainted 5.15.10-rt24-dirty #36
[ 22.288711] Hardware name: ARM Juno development board (r0) (DT)
[ 22.288718] Call trace:
[ 22.288722] dump_backtrace+0x0/0x1ac
[ 22.288747] show_stack+0x1c/0x70
[ 22.288763] dump_stack_lvl+0x68/0x84
[ 22.288777] dump_stack+0x1c/0x38
[ 22.288788] push_rt_task.part.0+0x364/0x370
[ 22.288805] rto_push_irq_work_func+0x180/0x190
[ 22.288821] irq_work_single+0x34/0xa0
[ 22.288836] flush_smp_call_function_queue+0x138/0x244
[ 22.288852] generic_smp_call_function_single_interrupt+0x18/0x24
[ 22.288867] ipi_handler+0xb0/0x15c
...
What about slightly changing the layout in switched_from_rt() (only lightly tested):
@@ -2322,7 +2338,15 @@ static void switched_from_rt(struct rq *rq, struct task_struct *p)
* we may need to handle the pulling of RT tasks
* now.
*/
- if (!task_on_rq_queued(p) || rq->rt.rt_nr_running)
+ if (!task_on_rq_queued(p))
+ return;
+
+ if (task_current(rq, p) && (p->sched_class < &rt_sched_class)) {
+ resched_curr(rq);
+ return;
+ }
+
+ if (rq->rt.rt_nr_running)
return;
rt_queue_pull_task(rq);
next prev parent reply other threads:[~2021-12-22 17:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-18 14:25 [RT] BUG in sched/cpupri.c John Keeping
2021-12-20 17:35 ` Dietmar Eggemann
2021-12-21 16:11 ` Valentin Schneider
2021-12-21 16:45 ` John Keeping
2021-12-21 17:22 ` Valentin Schneider
2021-12-21 17:42 ` John Keeping
2021-12-22 17:46 ` Dietmar Eggemann [this message]
2021-12-22 18:45 ` John Keeping
2021-12-22 19:48 ` Valentin Schneider
2021-12-23 11:58 ` John Keeping
2021-12-23 14:05 ` Valentin Schneider
2022-01-07 10:46 ` Dietmar Eggemann
2022-01-07 11:49 ` John Keeping
2022-01-07 14:25 ` Dietmar Eggemann
2022-01-07 18:35 ` John Keeping
2022-01-14 18:25 ` Valentin Schneider
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=31a47e99-6de3-76ec-62ad-9c98d092ead5@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=john@metanate.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).