linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
	Ingo Molnar <mingo@elte.hu>,
	linux-perf-users@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: perf timechart broken
Date: Tue, 11 Jan 2011 09:55:36 +0100	[thread overview]
Message-ID: <201101110955.37560.trenn@suse.de> (raw)
In-Reply-To: <20110111013625.GE2570@nowhere>

On Tuesday 11 January 2011 02:36:28 Frederic Weisbecker wrote:
> On Fri, Jan 07, 2011 at 11:04:37AM +0100, Thomas Renninger wrote:
> > Hi,
> > 
> > Latest x86 tip has another perf timechart issue introduce
> > by latest commits.
> > 
> > ./perf timechart
> > gives me:
> > "no trace data in the file"
> > 
> > I reverted  the latest changes and things seem to break
> > between d854861c4292a4e675a5d3bfd862c5f7421c81e8
> > and
> > 69aad6f1ee69546dea8535ab8f3da9f445d57328
> > (linux-2.6-x86 tree ids)
> > 
> > Be aware that ./perf timechart is currently broken
> > and segfaults on idle events (in 2.6.36 and 2.6.37).
> 
> You mean .36 perf tools faults on .37 kernel? or the opposite?
> Is it because power_idle events weren't present on old tools?
> Do you have a pointer to those patches?
perf timechart
will segfault if perf.data has power_{start,end} events included
on 2.6.36 and 2.6.37 kernels.

> > I submitted a patch to stable@ but it did not get accepted,
> > becaust it's not mainline yet.
> > I concentrated on my latest patches instead of making sure
> > the tiny fix gets into 2.6.37 first.
> > 
> > Ingo: It's a bit late for 2.6.37, if there is any chance
> > to still get it in, the patch below is against linus master...
> > otherwise I'll submit it for stable 36+37 asap.
> 
> It's too late for .37, but it's fine, we just need to add
> a "Cc: stable@kernel.org" tag in the patch for it to be
> backported.
I'll submit it to stable@ (it wasn't taken because
the patch which included the fix wasn't mainline yet and I
forgot to submit it for 2.6.37-rcX). 

I can take care of that, but it would be great if someone
could look at the issue that perf timechart shows:
"no trace data in the file"
in x86/tip which seems introduced by one of Arnaldo's latest
commits. Reverting some of his latest patches, solved it for
me.

> > Anyway to test above regression this mail is about, first
> > apply below patch otherwise you get a segfault if idle
> > (power_start/end) events got logged.
> > 
> > Thanks,
> > 
> >    Thomas
> > 
> > ---
> > perf timechart: Fix segfault on cpu idle (power_start/end) events
> > 
> > power_end event does not have type and other attributes and thus does
> > not match struct power_event.
> > Another struct could be created, but data.cpu is fine for fixing the segfault
> > and will work as long as C-states got initiated on the same CPU the idle state
> > takes place which is the case for all recent HW.
> > 
> > The power_start/end events get deprecated anyway, thus this is an easy,
> > riskless and sufficient solution for the segfault problem.
> > 
> > Signed-off-by: Thomas Renninger <trenn@suse.de>
> > CC: mingo@elte.hu
> > CC: arjan@linux.intel.com
> > 
> > ---
> >  tools/perf/builtin-timechart.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
> > index 9bcc38f..b3028eb 100644
> > --- a/tools/perf/builtin-timechart.c
> > +++ b/tools/perf/builtin-timechart.c
> > @@ -502,7 +502,7 @@ static int process_sample_event(event_t *event, struct perf_session *session)
> >  			c_state_start(pe->cpu_id, data.time, pe->value);
> >  
> >  		if (strcmp(event_str, "power:power_end") == 0)
> > -			c_state_end(pe->cpu_id, data.time);
> > +			c_state_end(data.cpu, data.time);
> 
> On which tree is this based of?
Linus master (2.6.37-rc8).

> What I have by looking at tip/master is:
Yes, this commit includes the patch (should have been a seperate one...):
20c457b8587bee4644d998331d9e13be82e05b4c
perf timechart: Adjust perf timechart to the new power events

   Thomas

> 
> 		else if (strcmp(event_str, "power:power_end") == 0)
> 			c_state_end(sample->cpu, sample->time);
> 
> >  
> >  		if (strcmp(event_str, "power:power_frequency") == 0)
> >  			p_state_change(pe->cpu_id, data.time, pe->value);
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2011-01-11  8:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-07 10:04 perf timechart broken Thomas Renninger
2011-01-07 12:33 ` Ingo Molnar
2011-01-11  1:36 ` Frederic Weisbecker
2011-01-11  8:55   ` Thomas Renninger [this message]
2011-01-11 11:49     ` Arnaldo Carvalho de Melo
2011-01-11 14:51       ` Arnaldo Carvalho de Melo
2011-01-14 16:49         ` Thomas Renninger
2011-01-14 17:37           ` Arnaldo Carvalho de Melo
2011-01-11 18:56     ` David Ahern
2011-01-14 17:00       ` Thomas Renninger
2011-01-14 17:09         ` David Ahern
2011-01-17 10:50           ` Thomas Renninger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201101110955.37560.trenn@suse.de \
    --to=trenn@suse.de \
    --cc=acme@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).