From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762717AbZEGOBO (ORCPT ); Thu, 7 May 2009 10:01:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1762095AbZEGN5G (ORCPT ); Thu, 7 May 2009 09:57:06 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:33117 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762081AbZEGN5F (ORCPT ); Thu, 7 May 2009 09:57:05 -0400 Date: Thu, 7 May 2009 15:56:45 +0200 From: Ingo Molnar To: Steven Rostedt Cc: linux-kernel@vger.kernel.org, Andrew Morton , Frederic Weisbecker , Li Zefan , Christoph Hellwig Subject: Re: [PATCH 3/7] ring-buffer: make moving the tail page a separate function Message-ID: <20090507135645.GC481@elte.hu> References: <20090507031335.815354104@goodmis.org> <20090507031434.018038090@goodmis.org> <20090507082717.GF12285@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Steven Rostedt wrote: > > On Thu, 7 May 2009, Ingo Molnar wrote: > > > > > * Steven Rostedt 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