Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
fs: Improve eventpoll logging to stop indicting timerfd
timerfd doesn't create any wakelocks; eventpoll can, and is creating the wakelocks we see called "[timerfd]". eventpoll creates two kinds of wakelocks: a single top-level lock associated with the eventpoll fd itself, and one additional lock for each fd it is polling that needs such a lock (e.g. those using EPOLLWAKEUP). Current code names the per-fd locks using the undecorated names of the fds' associated files (hence "[timerfd]"), and is naming the top-level lock after the PID of the caller and the name of the file behind the first fd for which a per-fd lock is created. To make things clearer, the top-level lock is now named using the caller command name and an "epollfd" designation, while the per-fd locks are also named with the caller's command name (to associate them with the top-level lock) and their respective fds' file names. Revert "Add kernel logging for when timerfd_read blocks" This reverts commit 47c748b. Adding logging to timerfd_read turns out to have been superfluous, since the blocking that occurs in timerfd_read properly relinquishes the CPU without holding any wakelocks. The logging also proved to be overly "chatty" due to frequency. Bug: 63866355 Bug: 38042165 Test: Ran on device and observed new wakelock naming in bugreport, dumpsys batterystats, /d/tracing/trace, and d/wakeup_reasons. Signed-off-by: Kelly Rossmoyer <krossmo@google.com> Change-Id: I4772c41a407afd17f87a6c15e01986c53ad0f9c0
- Loading branch information