Messages in this thread | | | Date | Thu, 17 Mar 2022 13:08:15 +0100 | From | Sebastian Andrzej Siewior <> | Subject | Re: sched_core_balance() releasing interrupts with pi_lock held |
| |
On 2022-03-16 21:27:34 [+0100], Peter Zijlstra wrote: > Now, we only do queue_core_balance() from set_next_task_idle(), which > *should* only happen from pick_next_task(), and as such the callback > should only ever get called from finish_lock_switch() or the 'prev == > next' case in __schedule(). > > Neither of these two sites holds pi_lock.
I've been trying to reproduce it and didn't make it. I see only the idle/scheduler path.
> This is about as far as I got explaining things, and it being late, it's > about as far as I got looking at things. > > Now that also makes conceptual sense, we only want to pull a core-cookie > task when we're scheduling an idle task. > > Now, clearly this gets triggered from the PI path, but that's not making > immediate sense to me, it would mean we're boosting the idle task, which > is wrong too.
Looking at the idle task, it shouldn't be possible for !RT due to lack of boostable locks and I don't see anything sleeping locks here on RT either.
> So it would be useful for someone that can reproduce this to provide a > trace of where queue_core_balance() gets called, because that *should* > only be in __schedule().
I failed so far.
Sebastian
| |