[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B6EB0@saturn3.aculab.com>
Date: Tue, 20 Mar 2012 11:41:46 -0000
From: "David Laight" <David.Laight@...LAB.COM>
To: "Indan Zupancic" <indan@....nu>,
"Eric Dumazet" <eric.dumazet@...il.com>
Cc: "Will Drewry" <wad@...omium.org>, <linux-kernel@...r.kernel.org>,
<linux-arch@...r.kernel.org>, <linux-doc@...r.kernel.org>,
<kernel-hardening@...ts.openwall.com>, <netdev@...r.kernel.org>,
<x86@...nel.org>, <arnd@...db.de>, <davem@...emloft.net>,
<hpa@...or.com>, <mingo@...hat.com>, <oleg@...hat.com>,
<peterz@...radead.org>, <rdunlap@...otime.net>,
<mcgrathr@...omium.org>, <tglx@...utronix.de>, <luto@....edu>,
<eparis@...hat.com>, <serge.hallyn@...onical.com>,
<djm@...drot.org>, <scarybeasts@...il.com>, <pmoore@...hat.com>,
<akpm@...ux-foundation.org>, <corbet@....net>,
<markus@...omium.org>, <coreyb@...ux.vnet.ibm.com>,
<keescook@...omium.org>
Subject: RE: [PATCH] net: bpf_jit: Simplify code by always using offset8 or offset32.
> On Tue, March 20, 2012 13:59, Eric Dumazet wrote:
> > On Tue, 2012-03-20 at 13:24 +1100, Indan Zupancic wrote:
> >
> >> If it does then perhaps the fast path should be made faster by
inlining
> >> the code instead of calling a function which may not be cached.
> >>
> >
> > inlining 400 times a sequence of code is waste of icache you
probably
> > missed this.
>
> Well, according to you most filters were small, inling 26 bytes a few
> times should be faster than calling an external function. Not
> all calls need to be inlined either.
I wouldn't bet on it.
If the number of arguments is small enough to fit in the registers,
the called function doesn't to save any registers, and the call
doesn't mean the calling code runs out of registers,
the actual cost of the call will be minimal.
OTOH the benefit of only having to fetch the code once,
and the higher likelyhood that it will be in the i-cache
from some other use, will make the version with the calls
faster.
You need to do real benchmarks on a real system running
a real workload to find out which is better.
Oh and beware that changes in which code shares cache
lines can have a measuarable effect (typified by unrelated
changes affecting measured performance).
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists