Re: [PATCH v2 06/16] xen: sched: tracing: enable TSC tracing for all events

[George Dunlap <george.dunlap@citrix.com>]

On 17/02/16 09:52, Dario Faggioli wrote:
> On Tue, 2016-02-16 at 13:21 -0500, Meng Xu wrote:
>> Hi Dario,
>>
>> Since this patch did some obvious change, I will reply with
>> reviewed-by, although my reviewed-by does not count much. ;-)
>>
> That can't be less true. First of all, you're the original author of
> this code, and you and, although I'm the maintainer, your group are the
> one doing active development on it, so your opinion does have a weight.
> 
> But even if that wasn't the case, every reviewed-by is important, and
> helps the project. It will be maintainers' and committer's job to
> properly take each one into account in the most appropriate way, but
> that does not mean it's not worthwhile for you (or anyone else) to
> review the patches and express your acknowledgment, or send in your
> comments. :-)
> 
> Actually, do feel free to do as much review (and, in case it applies,
> send in your reviewed-by tag) as you like and can, either on RTDS or
> anywhere else... The project is in great need of that!!
> 
>> On Tue, Feb 16, 2016 at 1:11 PM, Dario Faggioli
>> <dario.faggioli@citrix.com> wrote:
>>>  
>>> Note that this was not really a problem if looking
>>> at the traces with xenalyze, but it was if using
>>> xentrace_format.
>>
>> I just have a quick (and perhaps naive) question: :-)
>> If xenanlyze works better than xentrace_format, why shouldn't we
>> stick
>> to xenanlyze?
>> Is there some functionality xentrace_format can but xenalyze cannot?
>>
>> (I have to confess that I only used xenalyze but didn't use
>> xentrace_format before. :-()
>>
> xenalyze is indeed more advanced, but I don't think this means we
> should ignore or neglect xentrace_format: we've got it in tree, so we
> should not let it bitrot. I'm not in all our users' heads, so I don't
> know whether --and if yes why-- people may prefer the latter over the
> former, but I see room for someone wanting something basic and simple,
> in some cases.
> 
> Actually, I've been in a couple of situations myself, where the raw
> output of xentrace_format is easier to consume and, quick-&-dirtily,
> post-process, than the much more elaborated one of xenalyze.
> 
> For instance, the thing that you can just change on the fly the way a
> trace is shown (by tweaking the format file) looks an interesting
> feature to me, even considering all the limitations of "pure" xentrace.
> And if one want to change the formats for her own purposes, I feel like
> it is important that the one that we ship is updated, and can be used
> as a decent base for that.

So I certainly agree that xentrace_formats should be maintained so that
it works.  I hadn't thought before about the advantage of being able to
change the formats file more easily than adding new records to xenalyze,
but that's a good point.

But I do want to ask, how neccessary / useful is it to make the *TSC*
information available to xentrace_format?

The reason most of the traces don't include a timestamp is that it
increases the record size by a non-negligible amount -- in all the cases
here the traces are 1, 2, or 3 bytes without the tsc, so you're
basically doubling the size of what gets traced.

How does adding the TSC significantly help someone using xentrace_format?

 -George