[RFC PATCH] eventpoll: record task that adds to monitor list.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



While debugging latency issues for task waiting on epoll_wait, sometimes
it becomes necessary to see if the lower layer is invoking ep_poll_callback
timely for a given pid or not.

Recording task_struct in involved eppoll_entry's wait_queue_entry, allows us
to check this using a probe (say dtrace) at this function.
We could also achieve this by checking wait_queue_entry on eventpoll's
wait_queue_head itself, but that would involve more indirections.

Signed-off-by: Imran Khan <imran.f.khan@xxxxxxxxxx>
---

Since it just helps in debugging, I have kept the patch RFC.

 fs/eventpoll.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 3534d36a1474..3d4faf0a2d25 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1287,6 +1287,8 @@ static void ep_ptable_queue_proc(struct file *file, wait_queue_head_t *whead,
 	init_waitqueue_func_entry(&pwq->wait, ep_poll_callback);
 	pwq->whead = whead;
 	pwq->base = epi;
+	pwq->wait.private = current;
+
 	if (epi->event.events & EPOLLEXCLUSIVE)
 		add_wait_queue_exclusive(whead, &pwq->wait);
 	else
-- 
2.34.1





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux