From: Frederic Weisbecker <fweisbec@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Li Zefan <lizf@cn.fujitsu.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Tom Zanussi <tzanussi@gmail.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH 00/14] [GIT PULL][v2.6.39] tracing/filter: More robust filtering
Date: Tue, 15 Feb 2011 17:53:06 +0100 [thread overview]
Message-ID: <20110215165302.GA2272@nowhere> (raw)
In-Reply-To: <1297787362.23343.109.camel@gandalf.stny.rr.com>
On Tue, Feb 15, 2011 at 11:29:22AM -0500, Steven Rostedt wrote:
> On Tue, 2011-02-15 at 08:33 -0500, Steven Rostedt wrote:
>
> > Thanks for letting me waste three days on developing this. I even posted
> > an RFC a while back, and no one complained then.
>
> Sorry about being a bit bitchy in my reply here. I need to make a note
> not to reply to LKML before my first cup of coffee. ;)
>
> Arnaldo,
>
> Thanks for the post, I'll help you out where you need it. trace-cmd has
> some features that reports back to the user on failed filter usage. We
> can incorporate that into perf.
Cool!
That said I agree that we should not block improvements in the generic
filtering code because of issues in perf uses of filters.
I believe it used to work better in perf by the past, but I saw similar
issues lately like those Ingo noticed. So probably something
broke and we need to investigate. But until then your patches are
still nice improvements: lesser memory usage, lesser kernel stack usage in the
fast path, lesser limitation, faster and smarter filter evaluation...
next prev parent reply other threads:[~2011-02-15 16:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-08 1:56 [PATCH 00/14] [GIT PULL][v2.6.39] tracing/filter: More robust filtering Steven Rostedt
2011-02-08 1:56 ` [PATCH 01/14] tracing/filter: Have no filter return a match Steven Rostedt
2011-02-08 1:56 ` [PATCH 02/14] tracing/filter: Move OR and AND logic out of fn() method Steven Rostedt
2011-02-08 1:56 ` [PATCH 03/14] tracing/filter: Dynamically allocate preds Steven Rostedt
2011-02-08 1:56 ` [PATCH 04/14] tracing/filter: Call synchronize_sched() just once for system filters Steven Rostedt
2011-02-08 1:56 ` [PATCH 05/14] tracing/filter: Allocate the preds in an array Steven Rostedt
2011-02-08 1:56 ` [PATCH 06/14] tracing/filter: Free pred array on disabling of filter Steven Rostedt
2011-02-08 1:56 ` [PATCH 07/14] tracing/filter: Use a tree instead of stack for filter_match_preds() Steven Rostedt
2011-02-08 1:56 ` [PATCH 08/14] tracing/filter: Optimize short ciruit check Steven Rostedt
2011-02-08 1:56 ` [PATCH 09/14] tracing/filter: Check the created pred tree Steven Rostedt
2011-02-08 1:56 ` [PATCH 10/14] tracing/filter: Optimize filter by folding the tree Steven Rostedt
2011-02-08 1:56 ` [PATCH 11/14] tracing/filter: Move MAX_FILTER_PRED to local tracing directory Steven Rostedt
2011-02-08 1:56 ` [PATCH 12/14] tracing/filter: Increase the max preds to 2^14 Steven Rostedt
2011-02-08 1:56 ` [PATCH 13/14] tracing/filter: Swap entire filter of events Steven Rostedt
2011-02-08 1:56 ` [PATCH 14/14] tracing/filter: Remove synchronize_sched() from __alloc_preds() Steven Rostedt
2011-02-15 4:44 ` [PATCH 00/14] [GIT PULL][v2.6.39] tracing/filter: More robust filtering Ingo Molnar
2011-02-15 13:33 ` Steven Rostedt
2011-02-15 16:29 ` Steven Rostedt
2011-02-15 16:53 ` Frederic Weisbecker [this message]
2011-02-15 18:35 ` Arnaldo Carvalho de Melo
2011-02-16 13:34 ` Masami Hiramatsu
2011-02-16 14:52 ` Arnaldo Carvalho de Melo
2011-02-15 18:42 ` Ingo Molnar
2011-02-15 18:59 ` Steven Rostedt
2011-02-16 9:10 ` Ingo Molnar
2011-02-15 13:44 ` Arnaldo Carvalho de Melo
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=20110215165302.GA2272@nowhere \
--to=fweisbec@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tzanussi@gmail.com \
/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.