Re: [PATCH] ext3_clear_inode(): avoid kfree(NULL)

[Arjan van de Ven <arjan@infradead.org>]

On Sat, 2006-06-24 at 14:46 +0200, Arjan van de Ven wrote:
> On Sat, 2006-06-24 at 08:33 -0400, Steven Rostedt wrote:
> > On Sat, 24 Jun 2006, Arjan van de Ven wrote:
> > 
> > > On Sat, 2006-06-24 at 08:20 -0400, Steven Rostedt wrote:
> > > > On Sat, 24 Jun 2006, Arjan van de Ven wrote:
> > > >
> > > > >
> > > > > >
> > > > > > Because at that callsite, NULL is the common case.  We avoid a do-nothing
> > > > > > function call most of the time.  It's a nano-optimisation.
> > > > >
> > > > > but a function call is basically free, while an if () is not... even
> > > > > with unlikely()...
> > > > >
> > > > > sounds like a misoptimization to me.
> > > > >
> > > >
> > > > How is a function call free when an if is not?
> > >
> > > in general, a function call is 100% predictable without any real control
> > > flow dependencies for the processor, and thus there is no real issue in
> > > the execution pipeline. An if is a conditional branch, which breaks up
> > > the execution pipeline if mispredicted...
> > 
> > But doesn't the unlikely help the prediction? 
> 
> nope none at all, at least not on x86/x86-64.
> (in fact there is no way to help the prediction on those architectures
> that actually works)

ok that's not entirely accurate, there's some basic heuristics you can
tweak to; eg often the assumption is "if you jump backwards the branch
is taken" and stuff like that, but that's generally useful in loops, not
so much in if () statements.... since for if () both your branches are
forward.