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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 29/09/16 18:23, Dario Faggioli wrote:
> 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.

But if you're using xenalyze, xenalyze will know where the vcpu is
running / was last run; couldn't you have xenalyze report that
information when dumping the burn_credits record?

Again, I'm just pushing back to make sure the additional trace volume is
actually necessary. :-)

 -George


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