On Thu, Nov 14, 2024 at 07:12:31AM -1000, Tejun Heo wrote: > Hello, > > On Wed, Nov 13, 2024 at 10:59:08AM +0800, Zhao Mengmeng wrote: > > From: Zhao Mengmeng > > > > 1. replace hardcoding with SCX_KF_UNLOCKED. > > 2. scx_next_task_picked() has been replaced with siwtch_class(). > > 3. minor typo fixes. > > > > Signed-off-by: Zhao Mengmeng > > --- > > kernel/sched/ext.c | 6 +++--- > > tools/sched_ext/scx_qmap.bpf.c | 2 +- > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c > > index 1b1c33f12dd7..832f77d1d318 100644 > > --- a/kernel/sched/ext.c > > +++ b/kernel/sched/ext.c > > @@ -2759,10 +2759,10 @@ static int balance_one(struct rq *rq, struct task_struct *prev) > > * If the previous sched_class for the current CPU was not SCX, > > * notify the BPF scheduler that it again has control of the > > * core. This callback complements ->cpu_release(), which is > > - * emitted in scx_next_task_picked(). > > + * emitted in switch_class(). > > */ > > if (SCX_HAS_OP(cpu_acquire)) > > - SCX_CALL_OP(0, cpu_acquire, cpu_of(rq), NULL); > > + SCX_CALL_OP(SCX_KF_UNLOCKED, cpu_acquire, cpu_of(rq), NULL); > > I think this is actually a bug. David, shouldn't this be SCX_KF_REST? Yes, good catch. We're holding the rq lock so SCX_KF_UNLOCKED isn't safe. I agree this should be SCX_KF_REST. Thanks, David