How well would _this_ notion of an operating point scale up?
I have this feeling that it's maybe better attuned to "scale down"
sorts of problems (maybe cell phones) than to a big NUMA box. I can
see how a batch scheduled server might want to fire up only enough
components to run the next simulation, but I wonder if maybe systems
dynamically managing lots of resources might not be better off with
some other model ... where userspace makes higher level decisions,
and the kernel is adaptive within a potentially big solution space.
(Likewise, maybe some of the smaller systems would too.)
Also, I suspect everyone would be happier if cpufreq were left
responsible for the CPU-specific parts of an operating point.
That could mean system-specific hooks, e.g. to rule out certain
voltages based on available power or what devices are running.
Unfortunately, examples of non-CPUfreq part of an operating point
may be tricky to come by on desktop systems.
> Date: Tue, 09 Aug 2005 17:33:44 -0700
> From: Todd Poynor <[EMAIL PROTECTED]>
>
> Geoff Levand wrote:
>
> > I'm wondering if anything could be gained by having the whole
> > struct powerop_point defined in asm/powerop.h, and treat it as an
> > opaque structure at this level. That way, things other than just
> > ints could be passed between the policy manager and the backend,
> > although I guess that breaks the beauty of the simplicity and would
> > complicate the sys-fs interface, etc. I'm interested to hear your
> > comments.
>
> Making the "operating point" data structure entirely platform-specific
> should be OK. There's a little value to having generic pieces handle
> some common chores (such as the sysfs interfaces), but even for integers
> decimal vs. hex formatting is nicer depending on the type of value.
Taking a more extreme position or two:
- Why have any parsing at all? It's opaque data; so insist that
the kernel just get raw bytes. That's the traditional solution,
not having the kernel parse arrays of integers.
- Why try to standardize a data-based abstraction at all? Surely
it'd be easier to use modprobe, and have it register operating
points that include not just the data, but its interpretation.
- If those numbers are needed, having single-valued sysfs attributes
(maybe /sys/power/runstate/policy_name/XXX) would be preferable
to relying on getting position right within a multivalued input.
What I've had in mind is that "modprobe" would register some code
implementing one or more named runtime policies. Now one way to use
such code would be to equate "policy" and "operating point"; a static
mapping, as I think I see Todd suggesting, but compiled. (Or maybe
tuned using individual sysfs attributes.)
But another way would be to have that code pick some operating point
that matches various constraints fed in from userspace ... maybe from
sysfs attribute files managed by that code. It could use all sorts
of kernel APIs while choosing the point, and would clearly need to
use them in order to actually _set_ some new point.
It's easier for me to see how "echo policy_name > /sys/power/runtime"
would scale up and down (given pluggable policy_name components!)
than "echo 0 35 98 141 66 -3 0x7efc0 > /sys/power/foo" would.
> Since most values that have been managed using similar interfaces thus
> far have been flags, register values, voltages, etc. using integers has
> worked well and nicely simplified the platform backend, but if there's a
> need for other data types then should be doable.
Sysfs already has all that infrastructure, if you adopt the policy
that such system-specific constraints show up in system-specific
attributes somewhere ... matching the system-specific knowledge that's
used to interpret them. That'd also be less error prone than "whoops,
there wasn't supposed to be a space between 35 and 98" or "darn, I
switched the 141 and 66 around again".
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
