On Wed, Jan 12, 2022, Peter Zijlstra wrote:
> On Wed, Jan 12, 2022 at 05:30:47PM +0000, Sean Christopherson wrote:
> > On Wed, Jan 12, 2022, Peter Zijlstra wrote:
> > > On Wed, Jan 12, 2022 at 08:02:01PM +0800, Li RongQing wrote:
> > > > vcpu can schedule out when run halt instruction, and set itself
> > > > to INTERRUPTIBLE and switch to idle thread, vcpu should not be
> > > > set preempted for this condition
> > >
> > > Uhhmm, why not? Who says the vcpu will run the moment it becomes
> > > runnable again? Another task could be woken up meanwhile occupying the
> > > real cpu.
> >
> > Hrm, but when emulating HLT, e.g. for an idling vCPU, KVM will voluntarily schedule
> > out the vCPU and mark it as preempted from the guest's perspective. The vast majority,
> > probably all, usage of steal_time.preempted expects it to truly mean "preempted" as
> > opposed to "not running".
>
> No, the original use-case was locking and that really cares about
> running.
>
> If the vCPU isn't running, we must not busy-wait for it etc..
>
> Similar to the scheduler use of it, if the vCPU isn't running, we should
> not consider it so. Getting the vCPU task scheduled back on the CPU can
> take a 'long' time.
Ah, thanks. Should have blamed more, commit 247f2f6f3c70 ("sched/core: Don't
schedule threads on pre-empted vCPUs") is quite clear on this front.
