Re: [Xen-devel] [PATCH 10/24] xen: tracing: improve Credit2's tickle_check and burn_credits records
On Thu, 2016-09-29 at 18:28 +0100, George Dunlap wrote: > On 29/09/16 18:23, Dario Faggioli wrote: > > 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? > Yes, this is indeed a possibility. Xenalyze is not doing anything like or similar to that for now (at least, not in dump mode), that's probably why it did not occur to me that this could be done. But yeah, we've already discussed that it can become more intelligent and do more complex things and more refined reports, and this can well fit into that. > Again, I'm just pushing back to make sure the additional trace volume > is > actually necessary. :-) > Sure, that's fine! Ok, let's drop this patch for now then. :-) Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 10/24] xen: tracing: improve Credit2's tickle_check and burn_credits records
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@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 10/24] xen: tracing: improve Credit2's tickle_check and burn_credits records
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 -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 10/24] xen: tracing: improve Credit2's tickle_check and burn_credits records
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. 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? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
