On Mon, Jun 24, 2024 at 11:03:43AM -0700, John Stultz wrote: > 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. > > 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. > > 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 Hi John, Thanks for your feedback on this! I'm more than happy to add more details to the commit text. I'll go ahead and add an example to showcase a scenario where the proposed changes make debugging easier. I'll send out v6 of the patch soon. --Isaac
