Re: [Xen-devel] [PATCH 10/24] xen: tracing: improve Credit2's tickle_check and burn_credits records

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2016-09-20 at 15:35 +0100, George Dunlap wrote:
> On 17/08/16 18:18, Dario Faggioli wrote:
> > 
> > In both Credit2's trace records relative to checking
> > whether we want to preempt a vcpu (in runq_tickle()),
> > and to credits being burn, make it explicit on which
> > pcpu the vcpu being considered is running.
> > 
> > Such information isn't currently available, not even
> > by looking at on which pcpu the events happen, as we
> > do both the above operation from a certain pcpu on
> > vcpus running on different pcpus.
> 
> But you should be able to tell where a given vcpu is currently
> running
> from the runstate changes, right?  Obviously xentrace_format couldn't
> tell you that, but xenalyze should be able to, unless there were lost
> trace records on the vcpu in question.
> 
Well, yes and no. For instance, burn_credits() is not only called from
csched_schedule(), where indeed we have the information in close
records. It's also called from inside runq_tickle() itself (as we want
to update the credits of the various vcpus we are considering
preempting), which in turns can be called during vcpu wakeup.

In that case, knowing where a certain vcpu that we're asking to burn
its credit is running, may mean going quite a bit up in the trace, to
find its last context switch/runstate change, which is not always the
easiest thing to do.

It indeed can be scripted, but when _looking_ at a trace, trying to
figure out why you're observing this or that weird behavior, I think
knowing v->processor is a useful information.

> My modus operandi has been "try to keep trace volume from growing"
> rather than "wait until trace volume is noticably an issue and reduce
> it".  Presumably you've been doing a lot of tracing -- do you think I
> should change my approach?
> 
No, I think the approach is a good one. It's just that, in this case, I
think this is useful information, so I'll keep the patch in v2. But if
you're not sure, just ignore it, and we can sort this at another time.
:-)

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel