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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Feb 15, 2016 at 05:37:05PM +0100, Dario Faggioli wrote:
> 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@citrix.com>
> > 
> > .. 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.

.. How often do we do these operations?

> (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. :-)

Correct. This patch does fix the mis-use of the trace points.
> 
> 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)
>