[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CB3ED4D@AcuExch.aculab.com>
Date: Tue, 26 May 2015 15:47:19 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Eric Dumazet' <eric.dumazet@...il.com>
CC: 'Alexei Starovoitov' <ast@...mgrid.com>,
"David S. Miller" <davem@...emloft.net>,
Daniel Borkmann <daniel@...earbox.net>,
Eric Dumazet <edumazet@...gle.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net] x86: bpf_jit: fix compilation of large bpf programs
From: Eric Dumazet
> Sent: 26 May 2015 16:30
>
> > Yes, interesting, a benchmark that manages to run a lot of code 'cold cache'.
>
> We have binaries here at Google with 400 or 500 MBytes of text.
>
> Not benchmark, super real workloads you know.
Indeed, and a lot of the code is likely to be running 'cold cache'.
I was alluding to the problem where people will benchmark a small function
by running in 1000s of times in a tight loop with exactly the same data.
Not only is it 'hot cache' but any dynamic branch prediction is 'trained'
to the specific data.
David
Powered by blists - more mailing lists