Messages in this thread | | | Date | Mon, 4 Jul 2022 16:01:15 +0200 | From | Peter Zijlstra <> | Subject | Re: plumbers session on profiling? |
| |
On Fri, Jul 01, 2022 at 11:57:25AM -0700, Bill Wendling wrote: > On Fri, Jul 1, 2022 at 4:49 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > IIRC Google has LBR sample driven PGO somewhere as well. ISTR that being > > the whole motivation for that gruesome Zen3 BRS hack. > > > > Google got me this: https://research.google.com/pubs/archive/45290.pdf > > > Right. However, there's a chicken-and-egg issue with AutoFDO for the > production kernel. We can't release a kernel that hasn't been compiled > with PGO/FDO. We could only release it in a test environment, in which > case we could use AutoFDO. However, the document says that AutoFDO > only reaches ~90% of FDO. They list some reasons for this, but > nonetheless I suspect that the delta would be too severe for us to > release the kernel.
The pertinent question seems to be what's missing? Where does that 10% go.
> As for LBR, that will work with Intel/AMD, but I thought that LBR > doesn't exist for Arm processors (my knowledge could be out of date on > this).
Not totally up to date on the ARM thing either; but I believe you're right in that they don't yet have such a feature.
> What would make PGO (sample-based or instrumented) easy enough for you > to use? What're the key elements missing?
The key piece missing is how to feed a perf.data file back into the compile cycle, something like:
$ make O=build/ PERF=perf.data -j$lots
would be useful I suppose.
| |