All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@elte.hu>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Christoph Hellwig <hch@lst.de>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Li Zefan <lizf@cn.fujitsu.com>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Johannes Berg <johannes.berg@intel.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Tom Zanussi <tzanussi@gmail.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Andi Kleen <andi@firstfloor.org>
Subject: Re: [RFC] Unified Ring Buffer (Next Generation)
Date: Wed, 19 May 2010 20:10:01 +0200	[thread overview]
Message-ID: <20100519181001.GC18073@basil.fritz.box> (raw)
In-Reply-To: <1274291514.26328.930.camel@gandalf.stny.rr.com>

On Wed, May 19, 2010 at 01:51:54PM -0400, Steven Rostedt wrote:

Hi Steven,

> More than a year and a half ago (September 2008), at Linux Plumbers, we
> had a meeting with several kernel developers to come up with a unified
> ring buffer. A generic ring buffer in the kernel that any subsystem
> could use. After coming up with a set of requirements, I worked on

If we take a step back.

Why do you want a single ring buffer for everyone?

A lot more low profile subsystems subsystems simply use kfifo
(which is also actively developed by Stefanie). In fact there
are far more users of it than of your ring buffer. And it's 
really quite simple and easy to use. And it works fine for them.

I don't think it's that great a goal to have a single ring buffer
for all possible ring buffer needs. After all the requirements
are quite different.

Some want a simple ring buffer with minimal overhead
and simple interface, others need a mmaped one or have other special 
requirements. One size doesn't fit all. 

It's also not that we're talking about gigantic amounts of code
in all cases where there is a pressing need to unify.

If perf's current ring buffer works for it why not keep using it? 

One problem I always had with your version was that it's quite 
bloated frankly, especially in terms of code size, but 
also in its data structures and in the interface complexity.

For debugging kernels etc. with tracing that's not that big an issue, but
I think it's a problem for "non debugging" use. After all Linux
still has the goal to be at least configurable as a low footprint operating
system.

Part of the reason for its big code size seems to be that 
it tries to support everyone's requirements, which unsurprisingly
leads to some bloat both in implementation and interface.

Also to be honest it's so clever now that at least I have
a hard time understanding it, and I personally prefer code
that I can understand over too clever code. After all if there
is a bug in there and you need to be more clever than the programmer
to debug it, how would that be done? 

Perhaps a better goal would be to have a smaller simpler more
maintainable buffer for ftrace and let the other users their own?

Just my 0.05 cent.

-Andi


  reply	other threads:[~2010-05-19 18:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19 17:51 [RFC] Unified Ring Buffer (Next Generation) Steven Rostedt
2010-05-19 18:10 ` Andi Kleen [this message]
2010-05-19 18:44   ` Steven Rostedt
2010-05-19 19:25     ` Andi Kleen
2010-05-19 19:38       ` Steven Rostedt
2010-05-19 18:47   ` Mathieu Desnoyers
2010-05-20  6:41     ` Andi Kleen
2010-05-20 13:48       ` Mathieu Desnoyers
2010-05-19 19:05 ` Mathieu Desnoyers
2010-05-20  9:31 ` [RFD] Future tracing/instrumentation directions Ingo Molnar
2010-05-20 10:07   ` Frederic Weisbecker
2010-05-20 11:07     ` Thomas Gleixner
2010-05-20 11:42       ` Ingo Molnar
2010-05-20 11:48         ` Ingo Molnar
2010-05-20 12:15       ` Frederic Weisbecker
2010-05-20 12:19       ` Theodore Tso
2010-05-20 11:36     ` Ingo Molnar
2010-05-20 13:06       ` Frederic Weisbecker
2010-05-20 14:38   ` Steven Rostedt
2010-05-20 15:04     ` Steven Rostedt
2010-05-20 20:12     ` Steven Rostedt
2010-05-21 17:49     ` Ingo Molnar
2010-05-24 20:13       ` Steven Rostedt
2010-05-21  9:24   ` Li Zefan

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=20100519181001.GC18073@basil.fritz.box \
    --to=andi@firstfloor.org \
    --cc=acme@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=hch@lst.de \
    --cc=johannes.berg@intel.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --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=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --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.