15:05:55 <pknirsch> #startmeeting
15:06:27 <nirik> then you likely want a # meetingtopic (power sig?) or whatever. Then you can use topic to change topics... or the other commands. ;)
15:06:59 <pknirsch> #meetingtopic Power management for Fedora
15:07:21 <pknirsch> hm, i hope he switches the topic back to the old one when we end it ;)
15:07:31 <nirik> yep. It does. ;)
15:07:37 <pknirsch> good :)
15:08:11 <pknirsch> #info Current status: See http://fedoraproject.org/wiki/SIGs/PowerManagement
15:08:39 <pknirsch> The main topic today will be our plan for Fedora 12
15:09:14 <pknirsch> Feature page for Fedora 12 can be found here: http://fedoraproject.org/wiki/Features/PowerManagementF12
15:09:44 <pknirsch> As you can see, it's fairly small at the moment, but that due to the fact that feature freeze of F12 is coming in 3 weeks already, so not much time left
15:10:04 <pknirsch> here the overall scope for F12:
15:10:06 <pknirsch> *  Review and fix behaviour of typical applications in a full installed Fedora in regard to: [IN PROGRESS]
15:10:06 <pknirsch> o CPU wakeups
15:10:06 <pknirsch> o Disk IO
15:10:06 <pknirsch> o Network IO
15:10:06 <pknirsch> * Extend tuned
15:10:08 <pknirsch> o Integration of ktune and tuned: Static vs. dynamic tuning parts + performance vs. power tuning options
15:10:11 <fedbot> pknirsch: remove #fedora-meeting pknirsch : Please don't flood the channel, use a pastebin link like http://fpaste.org/ or http://dpaste.com
15:10:13 <pknirsch> o New monitoring and tuning plugin for CPUs (using PM-QOS for CPUs)
15:10:15 <pknirsch> o New disk tuning algorithm for a more gradual tuning
15:10:17 <pknirsch> * System tuning configuration and profiles
15:10:19 <fedbot> pknirsch: remove #fedora-meeting pknirsch : Please don't flood the channel, use a pastebin link like http://fpaste.org/ or http://dpaste.com
15:10:19 <pknirsch> o Introduce new CLI to allow switching between various predefined settings
15:10:21 <pknirsch> o Allow creating / editing / deleting profiles
15:10:23 <pknirsch> * Comprehensive documentation about system tunables
15:10:59 <pknirsch> The first big point is a continuation of what we've been looking at already since F7 and the introduction of the tickless kernel.
15:11:18 <pknirsch> New in F11 were the Disk and Network IO monitoring and auditing.
15:11:34 * nirik appologises for the flood notices. It shouldnt do that.
15:11:44 <pknirsch> ^^
15:12:21 <pknirsch> Nothing special about this goal: If you find an app thats waking up too often, doing too much disk or network IO open a bz and if possible find a fix for it.
15:12:43 <nirik> is there a tracker for these kinds of bugs we should use?
15:12:47 <pknirsch> Second big thing is about tuned. Thats the daemon that was introduced for F11 to do dynamic system tuning.
15:13:22 <pknirsch> We're now merging this with ktune, a static tuning framework which we've shipped already for RHEL-5
15:13:51 <pknirsch> so that we basically have all the tuning in one place instead of again spread out over a gazzilion applications
15:14:27 <pknirsch> In addition to that tuned will get a new monitoring and tuning pluging for CPUs using PM-QOS via devicekit-power (if available)
15:14:54 <pknirsch> And the disk tuning algorithm and mechanic will change a bit as it's currently not really usefull.
15:15:24 <pknirsch> The third big action point is a simple CLI tool to switch between various profiles for the whole system
15:16:16 <pknirsch> It will mainly just switch between different settings for ktune and tuned, but it'll make it much easier to do so (e.g. for kickstart installations)
15:16:32 <pknirsch> and you can then extend/change/add/delete profiles of course
15:17:40 <pknirsch> Last but not least there is the dreadful old documentation problem. As with many other parts of the OS having a comprehensive documentation about power management capabilities in one place will make it a lot easier again for people to actually use them.
15:18:29 <pknirsch> right now you'd have to know all the various sysctls and whatnot and read kernel documentation. that might be good for a developer, but a normal user can't really use that.
15:19:09 <pknirsch> Tuned since today has now also a real fedorahosted.org project page: https://fedorahosted.org/tuned/
15:19:28 <pknirsch> It still needs some content, but at least the group and the git repo is set up and everything.
15:20:03 <pknirsch> But the git repo is up to date and we'll use that to create the actuall releases
15:20:55 <pknirsch> We'll also be adding one more measurement tool for F12 (need to add that to the feature page actually): scomes
15:21:23 <pknirsch> it's a nice systemtap script that allows you to see improvements you made to an application and/or your system settings
15:21:57 <pknirsch> as it's currently really hard to measure any kind of success of improvement for changes to system settings and/or applications
15:23:27 <pknirsch> Thats about it though for today from my side. Anyone got any questions/concerns/ideas?
15:24:22 <nirik> I have a few newbie questions. :)
15:24:33 <pknirsch> sure! lets hear it :)
15:24:43 <sassmann> so is ktune integrated into tuned or the other way round?
15:24:52 <pknirsch> ktune will be integrated into tuned
15:24:54 <nirik> have you guys considered scheduling a test day? Then you could have people run their usual workload and report wakeups issues or the like...
15:25:46 <pknirsch> nirik: yes, we're planing to do one for F12 again. We've had one for F11 and it provided useful information, and hopefully with our new tools we'll get even better results this time.
15:25:48 <nirik> The profiles you talk of... what kinds of things are in a profile? on-battery/on-ac? or is that more machine types? or ?
15:26:47 <pknirsch> The idea here is to make several types of profiles. on-battery/on-ac would be one possibility, but we're also looking e.g. at desktop oriented and server oriented profiles
15:27:09 <sassmann> how easy is will it be to add custom "system tweaks" to tuned? Is there some kind of plug-in system?
15:27:18 <pknirsch> and as it's about general tuning also distinct profiles to tune for more performance or more power savings.
15:27:58 <nirik> pknirsch: how does it determine when to switch profiles?
15:28:22 <pknirsch> ye sassmann. for dynamic tuning you simple can write tuning and monitoring plugins (python based atm), for the static tuning we'll add the possibility to run scripts for each profile.
15:28:37 <pknirsch> the profiles themselves will be fix and selected by the user
15:28:56 <pknirsch> the dynamic part is then handled by the settings for that profile in the dynamic part of tuned
15:29:19 <pknirsch> (e.g. enable/disable dynamic disk/network/cpu tuning)
15:29:30 <pknirsch> so you could have a profile with only static tuning
15:29:42 <pknirsch> which would make it behave like the original ktune
15:29:56 <pknirsch> or you could have a profile with only dynamic tuning
15:30:06 <pknirsch> which then would be basically tuned only
15:30:32 <nirik> asking users to change profiles seems like a bad idea to me... ;)
15:30:46 <pknirsch> by default you shouldn't have to
15:30:50 <nirik> 99% of people will use whatever is the default. yeah.
15:31:47 <pknirsch> most of those profiles will contain tuning changes that will affect the performance of the system in order to save more energy
15:31:56 <pknirsch> but by default we don't want to do that
15:32:23 <pknirsch> so the default case will be a system with the maximum amount of power saving without loosing any visible performance.
15:33:12 <pknirsch> one example for that would be the changes that matthew garret did for graphic cards. in f11 some drivers now already contain power saving code and mechanisms with no impact on performance.
15:33:31 <pknirsch> and thats the thing we're trying to achieve first and foremost
15:33:39 <nirik> glad to hear it. ;)
15:34:12 <pknirsch> but we want to give the user the choice to save more power by sacrificing some performance, but without him having to know kernel details.
15:36:11 <pknirsch> long term wise there is quite a bit in the pipeline, but we'll add these things to the SIG and the subpages of the SIG over the next weeks/months
15:36:52 <pknirsch> most if it will require completely brand new hardware though, so not that overly interesting for normal users ;)
15:37:33 <skalnik1> pknirsch, could you more specify 'power saving code' in graphics cards?
15:38:38 <pknirsch> skalnik1: sure
15:38:47 <pknirsch> There are several things Matthew worked on:
15:38:58 <pknirsch> LVDS reclocking
15:39:31 <pknirsch> which basically reduces the refresh rate of the display when the screen is idle for LCD displays
15:39:58 <pknirsch> this works without any visual impact as the refresh rate is reset as soon as there is activity
15:40:19 <pknirsch> iirc this currently is in the intel driver
15:40:31 <pknirsch> 2nd one is GPU clock reduction
15:40:40 <pknirsch> thats in the intel and ati driver afaik
15:41:08 <pknirsch> and basically reduces GPU clock if there is no 3d activity
15:41:23 <pknirsch> very similar to what you already get from Windows drivers
15:41:37 <pknirsch> and last but not least GPU powerdown
15:41:53 <pknirsch> this is also in then ati and iirc intel driver
15:42:06 <pknirsch> and will power down the GPU completely if there is no display attached to it.
15:42:20 <pknirsch> very useful for servers without displays attached to it.
15:42:57 <sassmann> will that work for displays in powersave mode as well?
15:43:02 <nirik> are those just on by default?
15:43:08 <pknirsch> yes
15:43:26 <pknirsch> as those have no visual impact at all
15:43:48 <pknirsch> for 2d operations you won't notice any slowdown in operation with underclocked cards
15:44:15 <pknirsch> and displays with a proper powersave mode will disable the signal on the cable and allow the gpu to powerdown as well
15:45:06 <nirik> cool.
15:45:31 <pknirsch> and same for the LVDS reclocking. The display won't go darker with a lower refresh rate
15:45:37 <pknirsch> so no visual impact.
15:47:07 <pknirsch> hopefully over time more drivers will get those features, but it's a bit tricky for nvidia at the moment due to the non-existing documentation for all their chips
15:48:14 <ajax> practically speaking, there's only three drivers.
15:48:53 <ajax> also, you left out vram reclocking (which isn't enabled yet, still glitchy) and framebuffer compression
15:49:07 <pknirsch> ah yes, thanks ajax
15:49:20 * pknirsch points to ajax for more information about graphics drivers ;)
15:50:21 <pknirsch> is framebuffer compression on by default as well?
15:50:27 <sassmann> ajax: isn't framebuffer compression allready on?
15:50:33 <ajax> i think so, yeah
15:50:39 <ajax> although possibly not in all configurations
15:51:00 <pknirsch> ok, wasn't sure about the state of that. thanks.
15:51:51 <sassmann> ajax: how to enable framebuffer compression I just found (**) intel(0): Framebuffer compression disabled
15:52:11 <ajax> 'man intel', i assume
15:52:27 <pknirsch> Option "FramebufferCompression" "boolean"
15:52:32 <ajax> iirc there was some funny interaction between it and vsync interrupts
15:52:49 <sassmann> ajax: but we don't have /etc/X11/xorg.conf anymore ;)
15:53:05 <pknirsch> minor details ;)
15:53:18 <sassmann> pknirsch: that's how you call it ;)
15:53:24 <pknirsch> ^^
15:54:28 <sassmann> that's actually something that interests me, how to configure X w/o /etc/X11/xorg.conf around?
15:55:28 <nirik> you can make a xorg.conf just fine and X will use it.
15:56:34 <pknirsch> i would suspect that the latest xorg will then autoprobe/detect anything it can't find in the config file.
15:56:50 <sassmann> nirik: yeah but that's not the point :) If we ship w/o one there should be some way to configure it. Simply relying on X making the right choices isn't exactly helpful if you just wan't to change one minor detail like... hmm.. enabling framebuffer compression ;)
15:57:29 <wwoods> then you create one with one section in it
15:57:30 <pknirsch> #endmeeting