All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	David Miller <davem@davemloft.net>,
	Steven Rostedt <rostedt@goodmis.org>,
	Archs <linux-arch@vger.kernel.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH 0/7] perf updates and fixes
Date: Fri, 26 Mar 2010 18:38:44 +0100	[thread overview]
Message-ID: <20100326173841.GD5188@nowhere> (raw)
In-Reply-To: <20100326075817.GA27394@elte.hu>

On Fri, Mar 26, 2010 at 08:58:17AM +0100, Ingo Molnar wrote:
> 
> * Paul Mackerras <paulus@samba.org> wrote:
> 
> > On Fri, Mar 26, 2010 at 02:52:35AM +0100, Frederic Weisbecker wrote:
> > 
> > > The series is not yet mergeable because it would break PowerPc (hot regs 
> > > snapshot API has been changed, and I don't know how to update PowerPc for 
> > > that).
> > > 
> > > But if you're fine with the ideas, I can integrate the necessary changes 
> > > to fix this, and also separate fixes and updates.
> > 
> > The patch below adds the necessary stuff for powerpc.  You could fold it 
> > into your "perf: Move perf_arch_fetch_caller_regs into a macro" patch, or 
> > keep it as a separate patch in the series (though that would make preserving 
> > bisectability more difficult).
> 
> Since the series needs a resend anyway folding back ought to be fine i think.
> 
> I'm wondering whether this should get into tip:perf/urgent - or in 
> tip:perf/core for 2.6.35.
> 
> It fixes sw event call trace ugliness, but is that a 2.6.34 regression? Is 
> there any other aspect of the series that points towards accelerating this 
> into .34?


Let's have a look:

	perf: Correctly align perf event tracing buffer

Should probably go into urgent. The change is not invasive at
all. It doesn't fix a regression but it's still an important fix.

	The rest

It depends. The whole bunch is rather invasive.
The callchains of context switches never worked correctly
I think. I couldn't tell if the cpu migration has ever worked.
If it ever did, then it's a regression fix but in the middle of
too much hot regs improvements. So I can cook a specific fix for
the cpu migration event to work, and keep the rest for perf/core.

  reply	other threads:[~2010-03-26 17:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-26  1:52 [PATCH 0/7] perf updates and fixes Frederic Weisbecker
2010-03-26  1:52 ` [PATCH 1/7] perf: Drop the frame reliablity check Frederic Weisbecker
2010-03-26  1:52 ` [PATCH 2/7] perf: Fetch hot regs from the template caller Frederic Weisbecker
2010-03-26  1:52 ` [PATCH 3/7] x86: Unify dumpstack.h and stacktrace.h Frederic Weisbecker
2010-03-26  1:52 ` [PATCH 4/7] perf: Move perf_arch_fetch_caller_regs into a macro Frederic Weisbecker
2010-03-26  1:52   ` Frederic Weisbecker
2010-03-26  1:52   ` Frederic Weisbecker
2010-03-26  1:52 ` [PATCH 5/7] perf: Make perf_fetch_caller_regs rewind to the first caller only Frederic Weisbecker
2010-03-26  1:52   ` Frederic Weisbecker
2010-03-26  1:52   ` Frederic Weisbecker
2010-04-08  9:57   ` [BUG perf] perf_fetch_caller_regs / rewind_frame_pointer can panic Eric Dumazet
2010-04-08 10:59     ` Frederic Weisbecker
2010-04-08 12:32     ` [PATCH] perf: Fix unsafe frame rewinding with hot regs fetching Frederic Weisbecker
2010-04-08 12:32       ` Frederic Weisbecker
2010-04-08 13:52       ` Eric Dumazet
2010-04-08 17:31         ` [GIT PULL] perf fix Frederic Weisbecker
2010-04-13 22:51           ` Ingo Molnar
2010-03-26  1:52 ` [PATCH 6/7] perf: Use hot regs with software sched/migrate events Frederic Weisbecker
2010-03-26  1:52 ` [PATCH 7/7] perf: Correctly align perf event tracing buffer Frederic Weisbecker
2010-03-26  6:02 ` [PATCH 0/7] perf updates and fixes Paul Mackerras
2010-03-26  7:58   ` Ingo Molnar
2010-03-26 17:38     ` Frederic Weisbecker [this message]
2010-03-26 17:45   ` Frederic Weisbecker

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=20100326173841.GD5188@nowhere \
    --to=fweisbec@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=davem@davemloft.net \
    --cc=eranian@google.com \
    --cc=hpa@zytor.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.