linaro-pm-wg team mailing list archive

[Amit Kucheria <amit.kucheria@xxxxxxxxxx>]

On Tue, Jan 15, 2013 at 3:40 PM, Daniel Lezcano
<daniel.lezcano@xxxxxxxxxx> wrote:
> Blueprint changed by Daniel Lezcano:
>
> Whiteboard changed:
>   [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://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/WakeUpSources
> + 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.
>
>   Status:
>   Review

Yes, makes sense to make this information more accessible. BTW, how
does powertop show the per-process wakeups? Does it miss several
wakeups?

/Amit