[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Wed, Feb 17, 2016 at 4:52 AM, Dario Faggioli
<dario.faggioli@xxxxxxxxxx> 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!!

I see. Thank you very much for the advice and information! I got it now. :-D
I'm so glad to know that I can also comment on other parts of the
code, besides RTDS. :-D

>
>> On Tue, Feb 16, 2016 at 1:11 PM, Dario Faggioli
>> <dario.faggioli@xxxxxxxxxx> 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.

I see the point here now. I will try the xentrace_format next time then. :-)

Thanks and best regards,

Meng
-- 


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.