linux-kernel - RE: [linux-pm] Linux Power Management Mini-Summit -- Ottawa -- July 22, 2008

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <13B9B4C6EF24D648824FF11BE8967162035BBF861D@dlee02.ent.ti.com>
Date:	Mon, 30 Jun 2008 18:11:52 -0500
From:	"Woodruff, Richard" <r-woodruff2@...com>
To:	Len Brown <lenb@...nel.org>,
	Linux Power Management List <linux-pm@...ts.osdl.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: RE: [linux-pm] Linux Power Management Mini-Summit -- Ottawa -- July
 22,	2008

> Send suggestions for topics to linux-pm@...ts.osdl.org,
> whether you plan to attend or not.  The attendees will
> form the agenda by consensus at the start of the session.
>
> If you would like to attend, please send a note to
> linux-pm@...ts.osdl.org announcing your intent,
> and what you would like to discuss.

I would like to attend.

Main topics of interest would be run time PM.

We currently have ARM systems using cpuidle and going to 0v with full context loss between dynamic ticks.  There are a few areas it would be nice to get feed back on some hacks have had to be employed to get reasonable performance.

For example:
- we are saving driver state based on aggressive clock disables in drivers and only restoring context back on enable on control or event paths.  Doing this at the bottom of a driver stack like MMC means you don't always have good knowledge of what the stack has in store.  As such we add some activity timers to smooth it out.  But it would be nice to have some kind of idea about upper layer activity.

- With dynamic tick running you find needless one shot timer reprogramming (mainly from high interrupts during idle).  This can overflow the timer posting buffer and stall the MPU to a slower clock domain.  This results in really bad throughput.  Just keeping user space active and the periodic timer running instead of 1-shot will result in much better performance.

- How to account for demoted C-States?  Right now if a CPUIDLE BM check forces a state reduction compared to the menu governor chosen C-State there is no path to allow for residency accounting for the actual state entered.

Thanks,
Richard W.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/