Re: [PATCH 17/24] sched/fair: Implement delayed dequeue
From: Mike Galbraith
Date: Thu Oct 10 2024 - 13:13:45 EST
On Thu, 2024-10-10 at 09:18 -0700, Sean Christopherson wrote:
> On Thu, Oct 10, 2024, Mike Galbraith wrote:
> > On Wed, 2024-10-09 at 19:49 -0700, Sean Christopherson wrote:
> > >
> > > Any thoughts on how best to handle this? The below hack-a-fix resolves the issue,
> > > but it's obviously not appropriate. KVM uses vcpu->preempted for more than just
> > > posted interrupts, so KVM needs equivalent functionality to current->on-rq as it
> > > was before this commit.
> > >
> > > @@ -6387,7 +6390,7 @@ static void kvm_sched_out(struct preempt_notifier *pn,
> > >
> > > WRITE_ONCE(vcpu->scheduled_out, true);
> > >
> > > - if (current->on_rq && vcpu->wants_to_run) {
> > > + if (se_runnable(¤t->se) && vcpu->wants_to_run) {
> > > WRITE_ONCE(vcpu->preempted, true);
> > > WRITE_ONCE(vcpu->ready, true);
> > > }
> >
> > Why is that deemed "obviously not appropriate"? ->on_rq in and of
> > itself meaning only "on rq" doesn't seem like a bad thing.
>
> Doh, my wording was unclear. I didn't mean the logic was inappropriate, I meant
> that KVM shouldn't be poking into an internal sched/ helper.
Ah, confusion all better. (yeah, swiping other's toys is naughty)
-Mike