lkml.org 
[lkml]   [2009]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/7] ring-buffer: make moving the tail page a separate function

* Steven Rostedt <rostedt@goodmis.org> wrote:

>
> On Thu, 7 May 2009, Ingo Molnar wrote:
>
> >
> > * Steven Rostedt <rostedt@goodmis.org> wrote:
> > >
> > > +static struct ring_buffer_event *
> > > +__rb_reserve_next(struct ring_buffer_per_cpu *cpu_buffer,
> > > + unsigned type, unsigned long length, u64 *ts)
> > > +{
> > > + struct buffer_page *tail_page, *commit_page;
> > > + struct ring_buffer_event *event;
> > > + unsigned long tail, write;
> > > +
> > > + commit_page = cpu_buffer->commit_page;
> > > + /* we just need to protect against interrupts */
> > > + barrier();
> > > + tail_page = cpu_buffer->tail_page;
> > > + write = local_add_return(length, &tail_page->write);
> > > + tail = write - length;
> > > +
> > > + /* See if we shot pass the end of this buffer page */
> > > + if (write > BUF_PAGE_SIZE)
> > > + return rb_move_tail(cpu_buffer, length, tail,
> > > + commit_page, tail_page, ts);
> >
> > Nice! The __rb_reserve_next() fast-path logic became a lot clearer.
>
> Thanks!
>
> >
> > The above branch might be unlikely(), right? With usual record sizes
> > of around 40 bytes, we'll have a 100 records for every page
> > overflow. That's i think within the reach of unlikely().
> >
> > Depends on how much of a mess GCC makes of it though.
>
> I looked at the assembly that gcc generates, and it is fine. gcc
> inlines the function and puts it at the end, thus it already
> treats it as an unlikely. I would like to avoid adding unlikely
> annotations when possible.

Fair enough!

Ingo


\
 
 \ /
  Last update: 2009-05-07 16:05    [W:0.093 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site