[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0809261312310.21618@gandalf.stny.rr.com>
Date: Fri, 26 Sep 2008 13:14:23 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Masami Hiramatsu <mhiramat@...hat.com>
cc: Peter Zijlstra <peterz@...radead.org>,
Mathieu Desnoyers <compudj@...stal.dyndns.org>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
prasad@...ux.vnet.ibm.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Frank Ch. Eigler" <fche@...hat.com>,
David Wilder <dwilder@...ibm.com>, hch@....de,
Martin Bligh <mbligh@...gle.com>,
Christoph Hellwig <hch@...radead.org>,
Steven Rostedt <srostedt@...hat.com>
Subject: Re: [RFC PATCH v4] Unified trace buffer
On Fri, 26 Sep 2008, Masami Hiramatsu wrote:
> Peter Zijlstra wrote:
> >> I was going to reply to Masami with this answer, but it makes things more
> >> complex. For v1 (non RFC v1) I wanted to start simple. v2 can have this
> >> enhancement.
> >
> > Right - I just object to having anything vmalloc.
>
> I just requested that the expansion of buffer size limitation too. :)
>
> I don't stick with vmalloc. If that (page frame chain?) can
> achieve better performance, I agree that trace buffer uses it.
>
v5 is out with this implementation. It may or may not be better
performance, but the difference is most likely negligible.
Anyway, I'm happing with this last release, and hopefully it can get into
2.6.28. This would mean I can start basing ftrace on top of it.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists