On Thu, Jun 6, 2024 at 10:28 AM 'Isaac J. Manjarres' via kernel-team <kernel-team@xxxxxxxxxxx> wrote: > > From: Manish Varma <varmam@xxxxxxxxxx> > > timerfd doesn't create any wakelocks, but eventpoll can. When it does, > it names them after the underlying file descriptor, and since all > timerfd file descriptors are named "[timerfd]" (which saves memory on > systems like desktops with potentially many timerfd instances), all > wakesources created as a result of using the eventpoll-on-timerfd idiom > are called... "[timerfd]". > > However, it becomes impossible to tell which "[timerfd]" wakesource is > affliated with which process and hence troubleshooting is difficult. Thanks for sending this out! My apologies, as this is really meta-commentary (which I'm sure isn't what you're looking for), but as you've gotten limited feedback maybe it might help? While your explanation above is understandable, I feel like it might benefit from a more concrete example to show why this is problematic? It feels like the description gets into the weeds pretty quickly and makes it hard to understand the importance of the change. > This change addresses this problem by changing the way eventpoll > wakesources are named: > > 1) the top-level per-process eventpoll wakesource is now named > "epollN:P" (instead of just "eventpoll"), where N is a unique ID token, > and P is the PID of the creating process. > 2) individual per-underlying-file descriptor eventpoll wakesources are > now named "epollitemN:P.F", where N is a unique ID token and P is PID > of the creating process and F is the name of the underlying file > descriptor. Again the N:P.F mapping is clear, but maybe including a specific before and after example would help? Additionally, once you have this better named wakesource, can you provide a specific example to illustrate a bit on how this specifically helps the troubleshooting that was difficult before? thanks -john
