Messages in this thread | | | Date | Thu, 7 May 2009 15:56:45 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |