On Tue, May 10, 2022 at 2:31 AM Borislav Petkov <bp@xxxxxxxxx> wrote: > > > I haven't really done serious profiling work for a while (which is > > just as well, because it's one of the things that went backwards when > > I switch to the Zen 2 threadripper for my main machine) > > Because of the not as advanced perf support there? Any pain points I can > forward? It's not anything fancy, and it's not anything new - you've been cc'd on me talking about it before. As mentioned, I don't actually do anything fancy with profiling - I basically almost always just want to do a simple perf record -e cycles:pp so that I get reasonable instruction attribution for what the expensive part actually is (where "actually is" is obviously always just an approximation, I'm not claiming anything else - but I just don't want to have to try to figure out some huge instruction skid issue). And then (because I only tend to care about the kernel, and don't care about _who_ is doing things), I just do perf report --sort=dso,symbol and start looking at the kernel side of things. I then occasionally enable -g, but I hate doing it, and it' susually because I see "oh damn, some spinlock slowpath, let's see what the callers are" just to figure out which spinlock it ls. VERY rudimentary, in other words. It's the "I don't know where the time is going, so let's find out". And that simple thing doesn't work, because Zen 2 doesn't like the per-thread profiling. So I can be root and use '-a', and it works fine, except I don't want to do things as root just for profiling. Plus I don't actually want to see the ACPI "CPU idle" things. I'm told the issue is that Zen 2 is not stable with IBS (aka "PEBS for AMD"), which is all kinds of sad, but there it is. As also mentioned, it's not actually a huge deal for me, because all I do is read email and do "git pull". And the times when I used profiling to find things git could need improvement on (usually pathname lookup for "git diff") are long long gone. Linus