14:00:34 <jskarvad> #startmeeting PowerManagement
14:00:34 <zodbot> Meeting started Wed Feb  9 14:00:34 2011 UTC.  The chair is jskarvad. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:42 <jskarvad> Hi all
14:00:47 <jskarvad> news:
14:01:04 <jskarvad> The Developer conferece is approaching - http://fedoraproject.org/wiki/DeveloperConference2011
14:01:20 <jskarvad> It will start this Friday.
14:01:30 <jskarvad> We will have presentation there.
14:01:50 <jskarvad> I will post slides after the conf.
14:02:14 <jskarvad> I requested F15 Power Management testing day on 2011-03-24 - http://fedoraproject.org/wiki/QA/Fedora_15_test_days.
14:02:42 <jskarvad> I will prepare detailed instructions (after DevConf).
14:04:01 <jskarvad> Currently we are receiving feedback from users about the PM in Fedora.
14:04:10 <jskarvad> That's great.
14:05:17 <jskarvad> That's why we started Todos page (http://fedoraproject.org/wiki/SIGs/PowerManagement/Todos) where we would like to share our short and long term goals, ideas, users requests, worth to have PM features and so on...
14:06:51 <jskarvad> Next, does anybody know what is the current status of xhci (usb 3) suspend?
14:07:03 <jskarvad> I know that the code was removed from 2.6.37 as it was not yet ready.
14:10:14 <jskarvad> OK, I will try to search more. If anybody would know, please write me.
14:10:29 <jskarvad> I would like to see this feature in F15
14:11:34 <jskarvad> Next tuned.
14:11:49 <jskarvad> I played with the code and maybe I spot some possible problems.
14:12:06 <jskarvad> It seems that the PM-QoS cpu_dma_latency settings in dynamic cpu tuning plugin is not in effect.
14:12:34 <jskarvad> The code:
14:12:34 <jskarvad> open("/dev/cpu_dma_latency", "w").write(SETTINGS)
14:12:46 <jskarvad> in F14 Python interpreter writes the settings but immediately closes the handle.
14:13:12 <jskarvad> This behaviour seems not to be compatible with the PM-QoS specification as it states (the pm_qos_interface.txt):
14:13:27 <jskarvad> ...As long as the device node is held open that process has a registered request on the parameter....
14:13:37 <jskarvad> ...To remove the user mode request for a target value simply close the device node...
14:13:44 <jskarvad> Thus this handle should be probably hold open.
14:14:33 <jvcelak> jskarvad: send a patch, file a bug or add it onto the todo list and i will take care of it :)
14:15:16 <jvcelak> jskarvad: how can we verify, that it is working correctly?
14:16:43 <jskarvad> currently this settings should be counted by cpuidle, thus we could monitor if the CPU enters the C6 by setting this latency lower than C6 latency is
14:17:04 <jskarvad> than the CPU shouldn't enter the C6
14:17:41 <jvcelak> ok
14:18:51 <jskarvad> I also looked on the PS-Poll wifi settings
14:19:09 <jskarvad> I think I got it (the iwpriv vs sys)
14:21:01 <jskarvad> The iwpriv interface seems to work at least for Intel ipw2100 and ipw2200 cards.
14:21:56 <jskarvad> The /sys/power_level interface seems to work on some newer cards (iwl3945, iwl4965).
14:22:21 <jskarvad> It can be used to force the settings.
14:22:55 <jskarvad> But the mac80211 stack also counts with the PM-QoS and the PM-QoS should be used instead (AFAIK).
14:24:00 <jskarvad> Thus we could open the /dev/network_latency, write there the PS-Poll latency (max from the spec) and holding it open.
14:25:39 <jskarvad> Probably good to incorporate it into network dynamic tuning plugin
14:27:27 <jskarvad> Currently one BP candidate will experiment with such modifications.
14:27:57 <jvcelak> that's great.
14:28:55 <jskarvad> So we will see, but it seems promising.
14:30:30 <jskarvad> that's all from my agenda
14:31:10 <jskarvad> anything else?
14:31:28 <jvcelak> I don't have anything.
14:33:25 <jskarvad> ok, jvcelak: thanks for feedback ;) and lets meet again next week
14:33:35 <jvcelak> np ;)
14:34:31 <jskarvad> #endmeeting