Re: [RFC] Unified Ring Buffer (Next Generation)

From: Mathieu Desnoyers
Date: Thu May 20 2010 - 09:48:45 EST

* Andi Kleen (andi@xxxxxxxxxxxxxx) wrote:
> > The plan here is to create a ring buffer that supports per-buffer instance
> > "flags" that specify what must be supported: e.g. either splice() or mmap(),
> > global vs per-cpu buffers, etc.
> And you plan to test all those flags in the hot path?

No, I plan to make the hot path inline in the caller, so the flags can
statically select the proper behavior at compile-time. We can test flags
dynamically on the slow-path to save space.


> >
> > But all in all, I think users needing _something_ to perform system-wide tracing
> > shout a lot louder than users who need to save a few bytes. So let's try to get
> > something good in first, while keeping an eye on the object size, and if it
> > happens to be too large for some users, then they can always implement a
> > slower and less efficient ring_buffer_tiny.c if they feel like it.
> They don't need to, they already have kfifo.


> > I totally agree with you. This is in good part why I spent a large part of 2009
> > writing papers explaining my ring buffer, doing Promela models and formal proofs
> > of correctness. I think after all that work, the abstractions I will use will be
> > much easier to grap by anyone willing to do a bit of reading.
> Writing papers is not a replacement for simple maintainable code.

True. I rather mean "in addition to simple maintainable code".



Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at