Re: [Xen-devel] [PATCH v2] xen/sched: add some diagnostic info in the run queue keyhandler

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.02.2020 17:54, Jürgen Groß wrote:
> On 11.02.20 17:46, Jan Beulich wrote:
>> On 11.02.2020 14:10, Jürgen Groß wrote:
>>> On 11.02.20 14:01, Jan Beulich wrote:
>>>> On 11.02.2020 13:27, Juergen Gross wrote:
>>>>> When dumping the run queue information add some more data regarding
>>>>> current and (if known) previous vcpu for each physical cpu.
>>>>>
>>>>> With core scheduling activated the printed data will be e.g.:
>>>>>
>>>>> (XEN) CPUs info:
>>>>> (XEN) CPU[00] current=d[IDLE]v0, curr=d[IDLE]v0, prev=NULL
>>>>> (XEN) CPU[01] current=d[IDLE]v1
>>>>> (XEN) CPU[02] current=d[IDLE]v2, curr=d[IDLE]v2, prev=NULL
>>>>> (XEN) CPU[03] current=d[IDLE]v3
>>>>>
>>>>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
>>>>> ---
>>>>> V2: add proper locking
>>>>
>>>> "Proper" is ambiguous in the context of dumping functions. In a
>>>> number of places we use try-lock, to avoid the dumping hanging
>>>> on something else monopolizing the lock. I'd like to suggest to
>>>> do so here, too.
>>>
>>> All the scheduler related dumping functions are using the "real" locks.
>>> So using trylock in this single case wouldn't help at all. Additionally
>>> using trylock only would make a crash during dumping the data more
>>> probable, so I'm not sure we want that.
>>
>> Why would it make a crash more likely? If you can't get the lock,
>> you'd simply skip dumping.
> 
> Ah, okay, then I misunderstood your intention.
> 
> I still think that this should be done not only in one place, but in a
> more general fashion. I'd rather give up only after some time trying
> (1 millisecond per default?) and apply the same scheme to all dumping
> functions.
> 
> I can have a try for such a series if you agree on taking a more general
> approach.

Getting behavior consistent across key handlers would of course
be very nice.

Jan

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