tools: Show relation between timers and C state wake ups
This blueprint has been moved to JIRA: https:/
We want to investigate the role of
1. Timers that piggy-back on other wake ups - so they don't register as wake ups but could still be causing lots of system activity
2. Explicitly identify wakeup sources - timers that actually expired thus causing a system wakeup.
3. Correlation between C-states and timers
Blueprint information
- Status:
- Complete
- Approver:
- Vincent Guittot
- Priority:
- Low
- Drafter:
- Amit Daniel Kachhap
- Direction:
- Approved
- Assignee:
- Daniel Lezcano
- Definition:
- Superseded
- Series goal:
- Accepted for trunk
- Implementation:
-
Not started
- Milestone target:
-
backlog
- Started by
- Completed by
- Serge Broslavsky
Related branches
Related bugs
Sprints
Whiteboard
[amitk, 29/11/2012]: Daniel, please check if this is useful in your new tool as well. If not, let's close this blueprint.
[daniel-lezcano, Jan 14th, 2013]: When the identification of the interrupt is investigated from the POV of user space, it seems very hard to correlate efficiently the informations we want to collect as described in the WIs below.
[daniel-lezcano, Jan 14th, 2013] : Question for Amit : Shall we add a debugfs entry for cpuidle and begin to fill it with all the informations to investigate the cpuidle behavior ?
[daniel-lezcano, Jan 15th, 2013] : Elaborating a bit the previous comment.
We want to identify the reason of the wakeup, IOW who makes my cpu exit its idle state.
There are different sources of wakeup as identified in the document :
https:/
The timers are responsible, most of the time, of the wakeup. Identifying which timer, associated to a task (userspace, kernel) make the cpu to exit from idle, and identify what was the idle state we exited from, are informations very hard to correlate from the kernel traces.
These informations could be directly provided by the kernel in a pseudo filesystems like debugfs (sysfs is too limited for that and does not really fit this need). The /proc/timer_stats contains a lot of useful information and could be extended to add from which idle state we exited from.
[amit, Mar 26, 2013]: Yes augmenting existing information in /proc or /debugfs is a good idea.
Status:
Review
Work Items
Work items for backlog:
[robertdavidlee] Add information between events (timer and interruptions) and the C-state wake up: TODO
[robertdavidlee] Get for each cpuidle wake up which event has generated the wake up: TODO
[robertdavidlee] Display for each timers and interruptions how many wake up they have generated and from which C-State: TODO
Dependency tree
* Blueprints in grey have been implemented.
