On Tue, Jun 28, 2011 at 12:25 AM, Jan Kaluža <[email protected]> wrote: > On 06/07/2011 03:48 PM, Arjan van de Ven wrote: >> On 6/7/2011 4:45 AM, Jan Kaluža wrote: >>> Hi, >>> >>> attached patch adds new -s (--script) option to generate shell script >>> with commands to turn every "Bad" item from Tunables tab into "Good" >>> state. >>> >>> It adds new tunable::toggle_script() method which returns command to >>> switch state of particular tunable item and implements that method for >>> all current classes derived from "tunable". >>> >>> I'm open to suggestions. >> >> >> Hi, >> >> I would like some more opinions on this from people on the list. >> So initially my plan was to, instead of powertop show the shell >> tunables, document these in a website/document instead. >> That way there could be a better explanation of gotcha's, kernel >> versions etc etc.... think of it like a wiki. >> >> but people keep kinda wanting these things from the powertop program >> directly..... >> am I very wrong with the documentation idea? if so... yes we need >> something like your patch. >> > > Hi, > > what's the state of this one? Are there any news? I would like to know > if the patch is going to be accepted in some form (if I have to change > anything or so) or if it's generally bad idea.
We seem to be at an impasse, and people do not seem to understand why Arjan and me are largely against having this in the powertop program. I'll try to explain one more time. Powertop is first and foremost a tool to monitor power states in a dynamic, running system. The code base is entirely revolving around discovering what the impact of involved pieces of software have on the state of the system. In simple words: it's a "top" program that shows you the effect, of programs/code, when it runs (and in the specific way it runs), on power usage. Having a "meta" list of "static settings" will always be a secondary thing for powertop as a program. This means that we do not think that this is the most important part of the program, and will not be dedicating most of our coding time towards it. Why? Because we assume that if people are serious about saving power, they will already have tuned the "static configuration" optimally for the system. In effect, the "tunables" turn into a "look once, fix, then never look again" type of program. While all the other parts of powertop become something that one continuously looks at when developing systems, or operates them etc. Ultimately, therefore, having this functionality combined in the program is detrimental to both efforts. - We're carrying functionality around that we don't want to look at, or it's badly implemented (which was definately the case in powertop 1.0, and I've already seen complaints about it in pre-2.x), So it takes our time away from the 'top' part. - That functionality is deserving better, it's not getting developed properly. The obvious solution to me is to split the program: - power"top" - the 'top' part of powertop - show actual current states - power"tune" - the 'tune' parts - show kernel, system configs, and allow them to be adjusted These could live in the same git tree, which makes sense as the calibration code in powertop messes with some of the tunables... But having this as a separate tool means that a whole bunch of new programmers can go and contribute new functionality that Arjan and me have been hesitant to merge in the first place. The hard part is going to be starting from scratch, and coming up with a good way of doing tunables. We probably need to redesign some of the code we currently have to make it usable for new things that we might want to add in the future, such as more documentation, a plugin to automatically modify your kernel config, or save a suggested kernel config file etc.. Auke _______________________________________________ Power mailing list [email protected] https://bughost.org/mailman/listinfo/power
