Re: [PATCH for-4.22? 1/9] sched: introduce specialization of "running only" vcpu_runstate_get()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.06.2026 10:41, Roger Pau Monné wrote:
> On Mon, Jun 15, 2026 at 04:12:11PM +0200, Jan Beulich wrote:
>> About half the callers of vcpu_runstate_get() are solely after the
>> "running" time of a vCPU. Introduce a specialization with a smaller
>> read critical section and thus reduced risk of a need for retries.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Thanks.

>> --- a/xen/common/sched/core.c
>> +++ b/xen/common/sched/core.c
>> @@ -325,15 +325,35 @@ void vcpu_runstate_get(const struct vcpu
>>      }
>>  }
>>  
>> -uint64_t get_cpu_idle_time(unsigned int cpu)
>> +uint64_t vcpu_runstate_get_running(const struct vcpu *v)
>>  {
>> -    struct vcpu_runstate_info state = { 0 };
>> -    const struct vcpu *v = idle_vcpu[cpu];
>> +    struct seqcount seq = SEQCNT_ZERO();
>> +    const struct seqcount *s = v == current ? &seq : &v->runstate_seq;
> 
> Does it make a difference to use a local fake sequence counter or the
> real one if the vCPU is the one currently running in this pCPU?  If
> it's the running vCPU then it won't get the counters updated, and
> hence using the real or a fake counter won't matter, as it will never
> be updated while carrying out the read.  IOW: the usage of a local
> sequence counter for that specific case just adds more logic without a
> real benefit?

While the counter wouldn't be updated, adjacent items in struct vcpu may
be touched from remote CPUs. By using a stack variable we avoid possible
cache line bouncing in that case.

In any event - what is done here follows what vcpu_runstate_get() does,
i.e. this is meant to strictly be a special case thereof. If we wanted
to omit this extra logic, it should also (either first, or subsequently
in both places) be dropped from there.

Jan