tools: Show relation between timers and C state wake ups

Registered by Vincent Guittot

This blueprint has been moved to JIRA:

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

Vincent Guittot
Amit Daniel Kachhap
Daniel Lezcano
Series goal:
Accepted for trunk
Not started
Milestone target:
milestone icon backlog
Completed by
Serge Broslavsky

Related branches



[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 :
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.



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.

This blueprint contains Public information 
Everyone can see this information.