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

[Jürgen Groß <jgross@xxxxxxxx>]

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.


Juergen

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