Patch for Kernel 4.8.0

[Sjlver]

This is a set of changes that I did to make autofdo work with Linux 4.8.0.

This works for me, but no guarantees that it is correct. I basically copied content from various Kernel header files, and pattern-matched it against what was already in autofdo. My hope is that this pull request might nevertheless be a good starting point for an update.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[Sjlver]

I signed it!

[googlebot]

CLAs look good, thanks!

[abrodkin]

H Jonas,

I've just tried your patch with 4.8.4 kernel and see create_gcov failing.

That's my kernel info:

uname -a
Linux abrodkin-7440l 4.8.4-200.fc24.x86_64 #1 SMP Tue Oct 25 13:06:04 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

That's how I got my perf.data (trying to follow this article as close as possible - https://gcc.gnu.org/wiki/AutoFDO/Tutorial):

sudo ./ocperf.py record -b -e br_inst_retired.near_taken:pp -- ./sort_optimized

Bubble sorting array of 30000 elements
1628 ms
[ perf record: Woken up 6 times to write data ]
[ perf record: Captured and wrote 1.628 MB perf.data (3899 samples) ]

And finally running create_gcov:

./create_gcov --binary=./sort_optimized --profile=perf.data --gcov=sort.gcov -gcov_version=1
F1115 14:50:30.235198 20821 perf_reader.cc:991] Unknown event type 79
*** Check failure stack trace: ***
    @           0x440e24  google::LogMessage::Flush()
    @           0x443bd9  google::LogMessageFatal::~LogMessageFatal()
    @           0x428b36  quipper::PerfReader::IsSupportedEventType()
    @           0x428b98  quipper::PerfReader::ReadPerfSampleInfo()
    @           0x437884  quipper::PerfParser::MaybeSortParsedEvents()
    @           0x438fc9  quipper::PerfParser::ProcessEvents()
    @           0x43a724  quipper::PerfParser::ParseRawEvents()
    @           0x41c050  autofdo::PerfDataSampleReader::Append()
    @           0x41b5b3  autofdo::SampleReader::ReadAndSetTotalCount()
    @           0x4149b8  autofdo::ProfileCreator::ReadSample()
    @           0x4157b2  autofdo::ProfileCreator::CreateProfile()
    @           0x407c2e  main
    @     0x7f6e1583e731  __libc_start_main
    @           0x409099  _start
    @              (nil)  (unknown)
Aborted (core dumped)

I'm wondering if the same works fine for you?

Regards,
Alexey

[Sjlver]

I've tried the following on my machine. Note that I have Kernel 4.8.0; your version might have changes related to Perf.

# Works
gcc -O3 sort.c -o sort_optimized
perf record -b -- ./sort_optimized
create_gcov --binary=./sort_optimized --profile=perf.data --gcov=sort.gcov -gcov_version=1

# This one works, too
perf record -b -e branches -- ./sort_optimized
create_gcov --binary=./sort_optimized --profile=perf.data --gcov=sort.gcov -gcov_version=1

# This one doesn't... it doesnt' seem to recognize br_inst_retired.near_taken:pp
perf record -b -e br_inst_retired.near_taken:pp -- ./sort_optimized

I don't have ocperf.py... not sure what it does.

One of my motivations to write the patch was that I saw very similar error messages to you. I got Unknown event type 13. Turns out, 13 corresponds to PERF_RECORD_LOST_SAMPLES, so I added support for that into various files (see my patch).

Maybe you could check your kernel sources (kernel/perf_event.h) to see what 79 corresponds to, and add it in a similar manner?

[abrodkin]

ocperf is available here - https://github.com/andikleen/pmu-tools.

Well 79 looks like a bogus event, it is way too big number to be a real event. So I would assume this is because we're interpreting some data incorrectly but not sure which data - that definitely requires more in-depth look.

[evgeniy-paltsev]

ocperf.py is just perf wrapper.

So,

sudo ./ocperf.py record -b -e br_inst_retired.near_taken:pp -- ./sort_optimized

call results in

perf record -b -e cpu/event=0xc4,umask=0x20,name=br_inst_retired_near_taken,period=400009/pp ./sort_optimized

for me.

But it depends on host machine architecture.