fs: Improve eventpoll logging to stop indicting timerfd #1891
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Harmless and makes debugging life easier. MERGE |
|
NOOOO |
kholk
reviewed
Jan 24, 2019
fs/timerfd.c
Outdated
| @@ -387,6 +389,10 @@ SYSCALL_DEFINE2(timerfd_create, int, clockid, int, flags) | |||
| { | |||
| int ufd; | |||
| struct timerfd_ctx *ctx; | |||
| enum alarmtimer_type type; | |||
|
There's only an unused variable issue to solve, then it's fine. |
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 PID and an "epollfd" designation, while the per-fd locks are also named with the caller's PID (to associate them with the top-level lock) and their respective fds' file names. Bug: 63622255 Bug: 38042165 Test: Ran on device and observed new wakelock naming in bugreport, dumpsys batterystats, /d/tracing/trace, and d/wakeup_reasons. Change-Id: I32bfe5fe6766bb569329a450cc7163d52d59ed34 Signed-off-by: Kelly Rossmoyer <krossmo@google.com> Signed-off-by: ix5 <ix5@users.noreply.github.com>
|
Fixed unused var, compiled, booted, works. |
ix5
changed the title
|
Now there's no excuse for not merging it :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
cherry-picked from https://review.lineageos.org/c/LineageOS/android_kernel_xiaomi_jason/+/236442
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 PID and an "epollfd" designation, while the per-fd locks are also named with the caller's PID (to associate them with the top-level lock) and their respective fds' file names.