Hi Mikołaj, On Sat, Nov 23, 2024 at 09:49:40PM +0100, Mikołaj Kołek wrote: > I have found that when monitoring a file descriptor returned by > perf_event_open() with poll(), it is required to allocate an mmap ring > buffer to properly receive overflow notifications. If this is not > done, poll() keeps continuously returning POLLHUP, even when an > overflow notification should not be raised. Notably, this behavior is > different from listening for overflow notifications by setting the > O_ASYNC flag on the file descriptor - in that case, creating the mmap > ring buffer is not required to receive the SIGIO signal delivered > after the file descriptor becomes available for reading. I attach code > showcasing this behavior (the functionality is explained in the > comments). > > This behavior by itself is not a problem, however, in the current > state of the perf_event_open man page, it's not documented, and in > fact, there are confusing statements that seem to contradict my > findings. In the MMAP layout section of the page, you can find this > sentence: > Before Linux 2.6.39, there is a bug that means you must allocate > an mmap ring buffer when sampling even if you do not plan to > access it. > Unless I'm somehow misunderstanding it, this statement does not seem > to be well worded, or alternatively this bug does not seem to be > fixed. I would not call simply using poll() on the file descriptor > intent to access the ring buffer (unless it's meant to be understood > that way, in which case, in my opinion, it's quite confusing). > Additionally, I cannot find any change in Linux 2.6.39 that would fit > this description (however, that is likely just due to my lack of > experience searching through the kernel changelogs and commits). > > I would like to receive clarification on whether this current behavior > of perf_event_open is intentional and desired (that is why I cc'd > linux-perf-users). If it is, I could also create a patch to the man > page that lays out the requirements more clearly. In that case, it > would also be helpful to further clarify the wording of the sentence > mentioning the Linux 2.6.39 change, however I don't know if I'm > qualified to do that, because as I have previously stated, I am unable > to find what changes that sentence actually refers to. I don't know. Kernel maintainers may be able to respond much better than me. I see you've CCed their list, so they'll hopefully answer. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
