Re: [Xen-devel] [PATCH 03/14] xen: sched: fi position of TRC_SCHED_DOM_{ADD, REM}

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Mon, 2016-02-15 at 11:22 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 05, 2016 at 07:33:50PM +0100, Dario Faggioli wrote:
> 
> On the title you have 'fi', but I think you meant 'fix'.
> 
Indeed, sorry for that.

> > so that they actually live in the functions that
> > do the scheduling related domain initialization and
> > destruction.
> > 
> > Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
> 
> .. would it make sense to have an overall high-level
> 'DOM_ADD' and 'DOM_REM' trace ?
> 
> Especially as it is useful for figuring out how long
> an domain destruction takes time (based on the initial
> trace to say this TRC_SCHED_REM)?
> 
I think it makes sense, and I can either do this in this patch (and
resend) or as a follow up.

I guess the only possible concern is that we may introduce too much
tracing, to the point that it hurts performance, even when not enabled.
(I was starting to think about this anyway, as I've got other series,
either posted or in my queues, that adds a few more tracepoints,
because they're so damn useful! ;-P)

In that case, I guess we could think of doing something similar to what
ftrace does in Linux --for disabling and enabling tracing and
tracepoints-- which should be more lightweight than what we do.

In any case, none of this applies to a "DOM_ADD" / "DOM_REM" tracing
events. :-)

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
http://lists.xen.org/xen-devel