Messages in this thread | | | Date | Fri, 22 Jun 2012 17:51:49 -0700 | From | Arjan van de Ven <> | Subject | Re: [GIT PULL] perf fixes |
| |
On 6/22/2012 4:18 PM, Steven Rostedt wrote: > How so? It's not a C function call (like the -finstrument-functions > produces). It's an assembly function call. The only differences between > having ftrace enabled and ftrace disabled with -mfentry is that you get > a 5 byte nop at the start of each traceable function. Sure, it might put > a little pressure on the icache, but from the benchmarks I've run, the > impact has all been within the noise. > > I've been told that it doesn't even hurt the pipeline. But I've Cc'd hpa > and Arjan for their comments. How much impact does a 5 byte nop at the > start of each function really have on the normal operations of the > kernel? >
if it's truely an official nop, it will take decoder bandwidth obviously (which can decode 3 to 4 instructions per cycle, depending on the brand/model of CPU and the total size in bytes of these instructions). likewise, at the end of the out of order pipeline, NOPs may take a retirement slot (again 3 to 4 instructions per cycle)
icache is there as well, and if the NOP actually changes cpu flags (some of the less fortunate ones do) that can create a false data dependency.
I would also worry about the compiler being able to inline a function containing one of these, but that's a compiler thing, not a CPU type of thing.
| |