Re: [GIT PULL] Clang feature updates for v5.14-rc1

[Nick Desaulniers]

On Fri, Jul 2, 2021 at 11:58 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Fri, Jul 02, 2021 at 10:26:40AM -0700, Nick Desaulniers wrote:
> > On Fri, Jul 2, 2021 at 5:57 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> > > I've asked this before; *what* is missing from LBR samples that's
> > > reponsible for the performance gap?
> >
> > Are we able to collect LBR samples from __init code?  I can imagine
> > trying to launch perf from init/pid 1, but I suspect at that point
> > it's way too late.
> >
> > Increasingly, boot times of hosts (and virtualized guests) are
> > becoming important to us, both in the datacenters and on mobile.
>
> For a guest, possibly, I've no idea how any of that virt crud works.

Oh, another issue we've hit with LBR internally as well is the ability
to access them in virtualized guests.

It looks like support for those did land upstream a few years ago
though, so I'm not sure whether it's a question of us not having
backported/cherry-picked those internally (I'm not on the team
responsible for our datacenter kernels) or if there's some sysadmin
related restrictions where we block access to these MSRs for guests.

Either way, I had an intern last year (2 years ago, perhaps? how long
has this pandemic been...) looking into profiling LLVM, and we hit the
restriction where interns were only given access to VMs in the cloud,
and yet in these VMs could not access LBR.  "Guess we'll find
something else for you to work on then."

More of our developers are moving to cloud based VMs, where they have
access to larger build resources.  Perhaps we just need to work with
our sysadmins to get whatever capability is necessary, at least in
some limited capacity.

Opening a perf report is painful.  For a profile of a kernel build, we
get ~5GB of profile data with LBR, which takes a while to open (is
perf report single threaded?).  This is much better than via dwarf
based call graphs, at which point the data becomes exceedingly painful
to work with.  So LBR is a welcome improvement, when we have access to
it.
-- 
Thanks,
~Nick Desaulniers