Re: [Xen-devel] [PATCH v2 13/48] xen/sched: add is_running indicator to struct sched_unit

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.09.2019 15:44, Juergen Gross wrote:
> On 04.09.19 17:06, Jan Beulich wrote:
>> On 09.08.2019 16:57, Juergen Gross wrote:
>>> --- a/xen/common/schedule.c
>>> +++ b/xen/common/schedule.c
>>> @@ -407,6 +407,8 @@ int sched_init_vcpu(struct vcpu *v, unsigned int 
>>> processor)
>>>       {
>>>           get_sched_res(v->processor)->curr = unit;
>>>           v->is_running = 1;
>>> +        unit->is_running = 1;
>>> +        unit->state_entry_time = NOW();
>>>       }
>>>       else
>>>       {
>>
>> Are idle vCPU-s also going to get grouped into units (I'm sorry,
>> I don't recall)? If so, just like further down I'd be putting
>> under question the multiple writing of the field. I'd kind of
>> expect the unit and all vCPU-s within it to get an identical
>> state entry time stored.
> 
> When an idle vcpu is being created its cpu is in no cpupool yet
> (a free cpu). Those cpus are always subject to cpu scheduling
> (granularity 1). Only when cpus are put into a cpupool the
> granularity is adjusted accordingly and the idle-vcpus are
> possibly grouped in units (see patch 45).
> 
> Regarding the state entry time: different vcpus of a unit can be
> in different states (blocked/running, etc.), so their state entry
> times will generally differ. A unit's state entry time will
> reflect its scheduling events (being scheduled/descheduled).

But this doesn't (to me) clarify whether the multiple writing
(once per vCPU) is actually correct. Obviously whether this is
merely cosmetic depends on what the consumers of this data are.

>> Also both here and further down I'm puzzled to see that the
>> unit's field doesn't get set at the same place in code where
>> the vCPU's field gets set.
> 
> Right. The states of a vcpu and the unit it is belonging to are
> coupled, but not identical.

And this is not (going to be) a problem?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel