linux-kernel - Re: Power Management framework proposal

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]

Date:	Sun, 22 Jul 2007 11:56:04 -0700 (PDT)
From:	david@...g.hm
To:	Arjan van de Ven <arjan@...radead.org>
cc:	LKML <linux-kernel@...r.kernel.org>,
	linux-pm <linux-pm@...ts.linux-foundation.org>
Subject: Re: Power Management framework proposal

On Sun, 22 Jul 2007, Arjan van de Ven wrote:

>> this approach would allow the transition of ALL drivers to the new mode of
>> operation in one fell swoop, and then adding additional power management
>> features is just adding to the existing list rather then implementing new
>> functions.
>
>
> I have a concern with this approach though. It seems to assume that
> there is one global thing somewhere that sets the system state; in my
> experience that is the wrong approach; in fact there is a very definite
> evidence that there are many decisions on power that are to be made
> local at a high frequency. An example of this is the processor speed;
> the ondemand governer does exactly this for the cpus that can switch
> speeds fast; it's just impossible to beat such a local, fast decision
> with anything on a global scale.

the intent was not to have one global call that sets the mode on all 
devices, but rather have one call for each device/subsystem, just the same 
call in each case.

there's also nothing that says that there can only be one thing setting 
the mode (although that does mean a fourth call 'report_current_mode()' or 
similar is needed). and if you choose to have two pieces of software 
managing the same device things could get 'interesting'.

as for the speed that such decisions need to be made.

this API is not saying anything about the speed of the decisions.
it's also not saying anything about if the decision makeing is being done 
by kernelspace or userspace. it's just providing a common way for whatever 
software is doing the decision makeing to find out it's options and set 
the modes.

one way to represent this in sysfs (as a possible userspace API) would be
power/mode (read to see what mode the device is in, write to set the mode)
power/modelist
power/switching_delay (outputs the delay matrix showing the cost of switching from mode to mode)
although I'm not sure how you would allow the system to report an error 
this way.

if you have the ondemand governer running, it uses these API's to make 
it's changes, but if you didn't want to run the ondemand governer you 
could just do course speed settings through sysfs.

> On the other hand, some things (the high level goals and constraints)
> are obviously global.
>
> However, your design seems to want to put the low level settings in a
> global thing, and that is just a mistake.

I'm proposing a single function name per device, not a single function for 
the entire system.

David Lang
-
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/