perf_event sampling ring (mmap) buffers on architectures with large pages

[Daniel John FitzGerald <daniel.j.fitzgerald@gmail.com>]

I have a question about how to allocate and handle the mmap'd ring
buffer required by perf_event sampling on systems with potentially large
page sizes.

According to the perf_event_open man page:

        When using perf_event_open() in sampled mode, asynchronous events
        (like counter overflow or PROT_EXEC mmap tracking) are logged into a
        ring-buffer.  This ring-buffer is created and accessed through
        mmap(2).

        The mmap size should be 1+2^n pages, where the first page is a
        metadata page (struct perf_event_mmap_page) that contains various
        bits of information such as where the ring-buffer head is.

But what if the underlying architecture supports large page sizes?  If
my application were running on a modern POWER processor, there is a very
real possibility that it has been configured to use 16GB page sizes.  In
that case, I would be allocating a whopping 16GB of memory for the mmap
metadata page.  Is there a workaround to prevent the allocation of such
a large amount of memory for the mmap metadata page?

In addition to this question, I would be interested in hearing if anyone
has had to deal with any other issues related to perf_event sampling on
a system with large pages.

-- 
Regards,
Dan FitzGerald

An enlightenment painter would paint a grand house on a lawn;
A romantic painter would paint it on fire.