Re: [Xen-devel] [PATCH 0/4] enhance lock debugging

[Juergen Gross <jgross@xxxxxxxx>]

On 08.08.19 12:20, Andrew Cooper wrote:
> On 08/08/2019 10:36, Juergen Gross wrote:
> > On 08.08.19 10:33, Andrew Cooper wrote:
> > > On 08/08/2019 05:50, Juergen Gross wrote:
> > > > On 07.08.19 20:11, Andrew Cooper wrote:
> > > > > <snip>
> > > > > Its not exactly the easiest to dump to follow.
> > > > >
> > > > > First of all - I don't see why the hold/block time are printed like
> > > > > that.  It
> > > > > might be a holdover from the 32bit build, pre PRId64 support.  They
> > > > > should
> > > > > probably use PRI_stime anyway.
> > > > Fine with me.
> > > >
> > > > > The domid rendering is unfortunate.  Ideally we'd use %pd but that
> > > > > would
> > > > > involve rearranging the logic to get a struct domain* in hand.
> > > > > Seeing as
> > > > > you're the last person to modify this code, how hard would that be to
> > > > > do?
> > > > It would completely break the struct type agnostic design.
> > > Ok.  As an alternatively, how about %pdr which takes a raw domid?  It
> > > would be a trivial adjustment in the vsnprintf code, and could plausibly
> > > be useful elsewhere where we have a domid and not a domain pointer.
> > Lock profiling has no knowledge that it is working on a struct domain.
> > It is just working on a lock in a struct and an index to differentiate
> > the struct instance. Using the domid as the index is just for making it
> > more easy to understand the printout.
> >
> > I wouldn't want e.g. a per-event lock to be named "IDLE" just because
> > it happens to be index 32767.
> Ok, but clearly there is something which distinguishes domain indices
> from other indices?
Not for lock profiling.


Juergen

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