lkml.org 
[lkml]   [2005]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] no need to check for NULL before calling kfree() -fs/ext2/
From
Date
On Sun, 2005-03-27 at 15:51 +0300, Denis Vlasenko wrote:
> > > It's impossible to be otherwise. A call requires
> > > that the return address be written to memory (the stack),
> > > using register indirection (the stack-pointer).
> >
> > and it's a so common pattern that it's optimized to death. Internally a
> > call gets transformed to 2 uops or so, one is push eip, the other is the
> > jmp (which gets then just absorbed by the "what is the next eip" logic,
> > just as a "jmp"s are 0 cycles)
>
> Arjan, you overlook the fact that kfree() contains 'if(!p) return;' too.
> call + test-and-branch can never be faster than test+and+branch

ok so for the non-null case you have

test-nbranch-call-test-nbranch
vs
call-test-nbranch

vs the null case where you get
test-branch
vs
call-test-branch

(I'm using nbranch here as a non-taken branch; it's also a conditional
branch and it has the same misprediction possibility)

in the non-null case with if you have *two* chances for the branch
predictor to go wrong. (and "wrong" can also mean "cold, eg unknown"
here) and always an extra "test-nbranch" sequence, which is probably a
cycle at least

the offset for that is the null-case-without-if where you have an extra
"call", which is also half to a whole cycle.

even in the null case it's dubious if there is gain, it depends on how
the branch predictor happens to feel that day ;)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-06 13:30    [W:0.044 / U:7.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site