[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YjMkr4bE4Gws189a@linutronix.de>
Date: Thu, 17 Mar 2022 13:08:15 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>
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
Powered by blists - more mailing lists