Messages in this thread | | | Date | Thu, 7 Jul 2022 13:53:29 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH v3] sched/rt: fix bad task migration for rt tasks |
| |
On Fri, 8 Jul 2022 00:50:14 +0800 Schspa Shi <schspa@gmail.com> wrote:
> Please refer to the following scenarios.
I'm not sure this is what is happening. Do you have a trace to back this up?
> > CPU0 CPU1 > ------------------------------------------------------------------ > push_rt_task > check is_migration_disabled(next_task) > task not running and > migration_disabled == 0 > find_lock_lowest_rq(next_task, rq); > _double_lock_balance(this_rq, busiest); > raw_spin_rq_unlock(this_rq); > double_rq_lock(this_rq, busiest); > <<wait for busiest rq>> > <wakeup>
Here's the problem I have. next_task is queued on CPU0, (otherwise CPU0 would not be pushing it). As CPU0 is currently running push_rt_task, how did next_task start running to set its migrate_disable flag?
Even if it was woken up on another CPU and ran there, by setting migrate_disable, it would not be put back to CPU0, because its migrate_disable flag is set (if it is, then there's the bug).
After releasing the rq lock and retaking it, we check that the next_task is still the next task on CPU0 to push.
> task become running > migrate_disable(); > <context out> > deactivate_task(rq, next_task, 0); > set_task_cpu(next_task, lowest_rq->cpu); > WARN_ON_ONCE(is_migration_disabled(p)); > ---------OOPS-------------
I don't see how this can happen.
-- Steve
| |